Re: O_NOACCESS?

[Mouse <mouse%Rodents-Montreal.ORG@localhost>]

>> fexecve() makes a lot of sense too.  So would an flink(), [...]
> We'd want to be a bit careful about adding these as there are
> permission checks that are implied by specifying a path which you do
> not get with the f* calls mentioned.

Not per se, but the fd on the directory proxies for them, in that you
had to pass _its_ checks to get it.  I'd say that having an O_EXEC fd
on a directory should be possible exactly when you can do lookups on a
path leading to that directory; similarly for FREAD and FWRITE for
directory read and modification.  (IOW, if this isn't true, I think
something needs fixing.)

> Normally, these are not going to be terribly different but in the
> case of suid programs or chroot'ed programs, we'd want to analyse how
> we might change the security model.

Well, for set-ID programs, it's easy enough to just say the set-ID
program doesn't have to to use these calls if their characteristics
don't match the semantics it wants.  For chrooted programs, this
actually strikes me as a useful facility.  For example, using
SCM_RIGHTS to pass in a WRONLY fd onto an external directory could
allow a chrooted daemon to write a file into that directory _without_
(because the fd doesn't have O_EXEC) allowing the daemon to fchdir()
into it and thus escape the chroot.

This actually brings up an orthogonal point: it would be nice to be
able to downgrade a descriptor's capabilities by, for example, using
fcntl to set the open mode from O_RDWR to O_RDONLY....

If you don't want to go that way, you could just require that the fd
name a directory that's under the chroot in order for things to work.

                                        Mouse