Subject: Re: chroot(2)
To: None <tech-kern@netbsd.org>
From: der Mouse <mouse@Rodents.Montreal.QC.CA>
List: tech-kern
Date: 10/05/1998 15:30:50
> I was thinking about related issues earlier.  For orthogonality, it
> might be convenient to have an "fexec" syscall that gets the text
> vnode from a file descriptor-reference.

Good idea.  And I've often wished for flink(int, const char *).
Indeed, several potentially useful syscalls could be generated by
looking over the syscalls which take paths and considering

- Does the path just name a filesystem entity, and the call operates on
  that entity?  Then can it take a file descriptor instead?  (Many of
  these exist, eg, fchdir, fchmod, but some don't, eg, fexec, flink.)

- Is the path used merely to name a directory entry?  Then it can take
  a file descriptor on a directory, and a slash-free entry name within
  that directory.  (As far as I know, no such calls exist presently.
  Examples of calls where this could be done are unlink, or the link
  and symlink with respect to the second arg.)  A similar effect can be
  obtained with fchdir plus a relative name, but that requires search
  access to the directory, whereas some calls that could benefit from
  this don't.

This brings up another question: why do chdir and fchdir demand search
access to the directory?  It's entirely possible for a process to not
have search access to its cwd (if the access is removed after cwd is
established), and this doesn't break anything.  Yet - especially when
using fchdir and relative pathnames to simulate fd-plus-entry versions
of calls operating on directory entries - it can be useful to chdir to
a directory one can't search.

					der Mouse

			       mouse@rodents.montreal.qc.ca
		     7D C8 61 52 5D E7 2D 39  4E F1 31 3E E8 B3 27 4B