In some mail I received from Simon Burge, sie wrote
> 
> On Mon, 17 Nov 1997 19:35:39 +1100 (EST)  Darren Reed wrote:
> 
> > An example of what came to mind was some sort of trap back to a user
> > program which checked the request against a configuration file.  An
> > example would be you do "cd /home/web", it looks in its config file
> > which has something like "chdir user=!web /,!/home/web" and returns
> > saying "no, don't allow that chdir" - even if it is mode 777!
> 
> What about something like ACLs?  For the simpler cases, they'd be a more
> lightweight than a full blown external check.  (I know this is specific
> to file access, and you're talking about something a lot more general,
> but ACLs can come in handy.)

Because they require changes to the filesystem code.  Once you have ACL's
you then have to work out other things like: does tar copy them, will
dump/restore work with them, and related incompatibilities.  They're also
a lot tricker to code.  Where do they get stored, how do you reference them
from thee inode, etc.

HP cheated, I believe, on this issue.  The *ONLY* program which backs up
ACL's on HP-UX is fbackup and that only works with frecover.  dump won't
do them (but it will tell you that it skipped them) and neither does tar.

I'm not sure that Solaris2 will back them up either.

Anyway, the above was just an example and is not the only one possible.

Another could be "bind user=uucp family=inet,addr=*,port=25" allowing
the non-root user "uucp" to bind to port 25.  Another example might be
"setuid,seteuid user=* newuser=root auth=skey" to require skey
authentication for any transition from any user to "root" (I'm making
this up as I go :).  Of course then you need to allow programs like ping
to work...

The point I was trying to make is that if you have `complex' conditions
then you may not want to put it all in the kernel.

Darren