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