Ref:  Note from bg%nada.kth.se AT CARNEGIE.BITNET

> The user still wants to be "public" when his files are moved to AFS so
> he puts system:anyuser rl on the new home directory. But now he discover
> that everybody can read his mbox and he goes mad and call me all kinds
> of names. Then I suggest that he make a private directory where he might
> keep his secret files and use symbolic links to put them in his top
> directory. But very soon you realize that many programs unlink that
> symlink when they update the file and now the file is public again.

We have exactly the same problem. We decided for the symlink solution,
but it is a BIG mess. Therefore, we now have only system:anyuser l on our
home directories. This avoids security exposures when a symlink breaks,
and it takes care of the fact that many programs create files in your
home directory without your being aware of them. Such files may well
hold confidential data, e.g. a temporary printer output file. Whenever
we create a new subdirectory, we have to open it to the public explicitely.
And if you organize your stuff in a decent way, there won't be much
data of public interest in your home directory anyway. We took the approach
to use symlinks for stuff we want to be public, e.g.
  mkdir .Profiles
  fs sa .Profiles system:anyuser read
  mv .profile .Profiles
  ln -s .Profiles/.profile .profile

> One thing that could be used to solve this particular problem would be
> to use the unix others rwx bits instead of the unix owner rwx bits
> whenever a file is accessed by a user who is implicitly on a
> particular list. Here implicitly means that the user has access right
> because he is on the system:anyuser, system:authuser or on a
> particular network.

Why not something like this:
  owner              may do what user bits allow, no matter what the ACL is
  people on the ACL  may do what group bits say, and'ed with the ACL
  system:anyuser     may do what others bits say, no matter what the ACL is
This approach would have been much more consistent with standard *IX
file protections, but I am quite sure it is much too late for a change.

Michael Niksch

Reply via email to