[OpenAFS] ACL for single files
Sun, 19 Sep 2004 19:14:14 +0200
* Mike Fedyk [2004-09-19 00:50:36 -0700]:
> Hartmut Reuter wrote:
> >In our MR-AFS fileservers we have an optional switch on volume basis
> >which allows to use the modebits for other to control the access of
> >unauthenticated users (system:anyuser). This certainly could be
> >easily in OpenAFS fileservers as well.
> >We didn't set this flag automatically for all user volumes because it
> >the access: If someone has given read access on the root directory of
> >his home volume to system:anyuser then after switching this feature
> >on only
> >files with the the other-read-bit on remain accessable. So it requires
> >new unusual attention of the users.
Doesn't it also risk widening access? What exactly does the patch do if
the directory's ACL has "system:anyuser rl" but a file in it has o=rw ?
I'm particularly worried about the interaction of this feature with
the hack (used by OpenAFS on Mac OS X, in order to work around the
tendency of Apple's Finder to cache file access permissions)
of stat() returning the owner mode bits also for group and others.
That's no problem when reading a file from Mac OS X, but an AFS-to-AFS
"cp -p" can easily set the new file's mode to 666.
(OK, it's an issue for AFS-to-HFS+/UFS as well, and there the user had
better understand the implications of the -p option. But AFS directories
are potentially exported worldwide, which increases the exposure from
overly lax file permissions.)
> It will greatly ease transitions from installations that already only
> use the standard UGO octal unix permissions. Adhering to setting the
> same group as parent with the SGID bit set on directories would be
> needed also.
Indeed the SysV setgid directory semantics would be nice to have, and
my reservations don't seem to apply. Actually, I'd really like to be
able to chmod g+s an AFS directory in the first place: it would work
around a problem I've encountered with GNU arch. (When the arch'ive
contains a setgid directory, checkouts into AFS will fail because
GNU tar returns non-zero when it has been asked to preserve permissions
but cannot do it.)