On ACLs

You commented that you would like more letters so I thought I would
spend a few minutes writing something - something on the topic of ACLs
which as you noted caused a lot of discussion and differing opinions
on linux-kernel.

For myself I think that it is sad that ACL support had to go into
Linux.  Not sad that it *did*, but sad that it *had to*.
Linus is ever the pragmatist, and including support for ACL's
is certainly the pragmatic thing to do.  But I think that the
environment that makes it a pragmatic decision is sad.

You see, I would rather go in the opposite direction, and remove what
ACL's we do have from being supported by the kernel:  they aren't
needed, and are often 'wrong', except in the simplest cases.

They aren't needed because I have access to much more flexible ACL's
completely outside of the kernel.  Apache, for example, provides very
flexible access control via the .htaccess file and various 'require'
directives and authentication mechanisms.  These mechanisms allow
people to create their own groups and give access based on patterns
in filenames, both features that are very useful and unlikely to be
supported by any ACL mechanism that is embedded in the kernel.

You might think that apache's access control only allows control of
read access, but write access is also very much a possibility.  By
defining a few generally applicable 'PUT' handlers (e.g. one which
will append, one which will check-in to RCS first, etc) a sysadmin
can make it fairly straight forward for users to give controlled write
access to files as they choose.

And this leads to the second issue, that current ACLs (and by that I
mean UNIX rwx for each of ugo) are wrong except in the simplest cases.

Giving anyone else unfettered write access to your files is probably a
bad idea.  We have a long history of how much of a bad idea a world
writable /tmp is, and group-writable directories aren't really much better.
The issues with others-writable files aren't so bad, but still, in
most cases you would really like some sort of control.  Possibly
allowing others to append, providing their username appears first
would be ok.  Possibly checking the file into a revision control
system before making a change would be ok.  But un-checked write
access just isn't sensible.

Obviously some files would benefit from much more subtle access
control rules.  Your example of /etc/password as mentioned in the
article on reiser4 is a good one.  Some people possibly should have
write access to some parts of their own record.  Some people might be
denied read access to some fields of other people's records.  Hans
Reiser, it would seem, would like to embed all that knowledge in the
filesystem.  I would rather lift it all up and embed it in some
user-space service.  Quite possibly that service could present a
filesystem-like interface (as I'm sure it would in plan-9) and that
interface could be 'mounted' into the filesystem name-space.  But
embedding knowledge of such access controls in the kernel is, to me,
wrong.


So what is my grand vision (which will never eventuate due to the
weight of current-practice)?

- File systems do not store any ownership/access control information.
- File systems are mounted either readonly, or writable.  / and /usr
  are readonly.  /home (which will only contain my home) is writable.
- Each process has a separate 'mount table' and associated view of the
  name space (this is coming to Linux if it isn't here already).
  My processes see my home directory, your processes see yours.
- Access to other people's personal filesystems have to be through
  some sort of gateway, such as apache/http.  Such gateways would be
  able to impose arbitrary access controls as appropriate.
  There may well be a very light weight gateway that provides everyone
  with read-only access to a certain part of other peoples home
  directories (e.g. /home/public) to make sharing easier.
- These gateways would use cryptographically secure identities (much
  like ssh does, and possibly using something like ssh-agent to
  supply them) so they could easily and securely be either remote or
  local.

Thus we lift the whole ACL issue out of the kernel and place it
clearly in user-space.  As there doesn't seem to be clear agreement
about what ACLs should really look like anyway (witness the Posix
draft that nobody seems to like), I think the flexibility of being in
user-space is a good thing.

Doing away with access bits does mean that we loose the 'x' bit.  But
having non-executable files in directories in your PATH is a bit
pointless anyway, and the kernel already knows what files are
executable based on 'magic numbers'.
The 'x' bit of directories doesn't add anything useful over the 'r'
bit.

It would also mean loosing the possibility of removing write access
from files that you own.  This (the 'user-write' bit) is probably the
only permission bit that might be worth leaving, but I would want to
think about it some more before I was certain that (in the ideal
world) we should even keep that.


I think filesystems should be left to store files and names of files
  (and symlinks/devices I guess)
I think inter-person access control should be left to user-space
  daemons which are in a position to be more flexible than any ACL scheme
  that a kernel/fs developer is likely to come up with.
I think the filesystem interface is likely to be a good interface for
  accessing such daemons, but that is quite different from embedding
  the daemons functionality in a filesystem.

As a sort of summary, it seems a pity to have to include a
questionable feature due to outside pressure.
It is true that having ACL support in the kernel doesn't preclude me
from coming up with a system that doesn't need it.  However as
Linus said recently on another matter (LKCD I think it was), a problem
with including something that is 'good' but might not be 'best' is
that it reduced the incentive to create the 'best' thing.  I feel that
logic could apply to ACLs.

NeilBrown