On Thu, Apr 25, 2002 at 02:51:49PM +0200, Andreas Gruenbacher wrote:
> So this is the promised response to the suspected inheritance bug. To
> reestablish the contect, here is Ethan's original posting:
>
>
> On Wed, 17 Apr 2002, Ethan Benson wrote:
> >
> > i am trying to set a default acl to allow a user read permission to
> > files created.
> >
> > so do:
> >
> > root@ash:/var/log/apache# setfacl -dm u:webstats:r-- .
> >
> > which renders:
> >
> > root@ash:/var/log/apache# getfacl .
> > # file: .
> > # owner: root
> > # group: root
> > user::rwx
> > group::r-x
> > other::r-x
> > default:user::rwx
> > default:user:webstats:r--
> > default:group::r-x
> > default:mask::r-x
> > default:other::r-x
> >
> >
> > and then touch foo and get its permissions:
> >
> > root@ash:/var/log/apache# touch foo
> > root@ash:/var/log/apache# getfacl foo
> > # file: foo
> > # owner: root
> > # group: root
> > user::rw-
> > user:webstats:r-x #effective:r--
> > group::r-x #effective:r--
> > mask::r--
> > other::r--
> >
> > why is the group and webstats user being given execute permission?
> > (yes i know the mask revokes it, its still wrong and i don't want any
> > user/group to have an x bit on *files*)
> >
> > when creating a file no execute bits should be set for anyone, why
> > does this not work correctly? note this test is done on the SGI
> > 2.4.18 XFS split patches. with acl 2.0.8.
>
> Either something has gone wrong on your example above, or there is indeed
> a bug in the XFS ACL implementation. No execute bit for user webstats
> should ever spring into existence like this.
i fiddled around with it for well over an hour trying to stop this
behavior, i am quite certain about the above results (which are
copy/pasted directly from my tty). in between tests i always
completly stripped the acls with setfacl -b and verified that even the
system.*acl* attrs were removed with getfattr -m .
>
> In this particular situation, the correct ACL of the file foo would be:
>
> $ getfacl foo
> # file: foo
> # owner: ag
> # group: users
> user::rw-
> user:webstats:r--
> group::r-x #effective:r--
> mask::r--
> other::r--
>
> Ethan, could you please verify that this is what actually happens?
> Otherwise, we should indeed file a bug report.
i already verified it umteen times before i finally mailed you asking
wtf was going on.
>
> Apart from that, the usual permissions for users/groups who shall get
> read/search access to a directory tree are `r-x' (and `rwx' for
> read/write/search access), however. This allows users also to
> search/change into directories created.
yes the behavior on directories is exactly as i would expect.
> As you have observed, the effective permissions are automatically
> restricted by the mode parameter specified when creating
> files/directories. Usually, this mode parameter is 666 for files, and 777
> for directories. It is alright to rely on the ACL mask entry to mask off
> permissions.
ok perhaps, but it seems wrong and hackish IMO.
> This is what you would usually do/get:
>
> $ mkdir dir
> $ setfacl -m u:webstats:rx dir
> $ setfacl -dm u:webstats:rx dir
> $ getfacl dir
> # file: dir
> # owner: ag
> # group: users
> user::rwx
> user:webstats:r-x
> group::r-x
> mask::r-x
> other::r-x
> default:user::rwx
> default:user:webstats:r-x
> default:group::r-x
> default:mask::r-x
> default:other::r-x
>
> $ touch dir/file
> $ getfacl dir/file
> # file: dir/file
> # owner: ag
> # group: users
> user::rw-
> user:webstats:r-x #effective:r--
> group::r-x #effective:r--
> mask::r--
> other::r--
you get the same results as me, user webstats anomolously getting
execute permission.
> $ touch dir/subdir
> $ getfacl dir/subdir
> # file: dir/subdir
> # owner: ag
> # group: users
> user::rwx
> user:webstats:r-x
> group::r-x
> mask::r-x
> other::r-x
> default:user::rwx
> default:user:webstats:r-x
> default:group::r-x
> default:mask::r-x
> default:other::r-x
this is what i get for directories as well, and i find this normal.
its the file behavior which is wrong IMO.
>
> The design alternative of removing all permissions from all ACL entries
> that are not contained in the create mode would yield this result:
>
> $ getfacl dir/file [ does not represent the implemented behavior! ]
> # file: dir/file
> # owner: ag
> # group: users
> user::rw-
> user:webstats:r--
> group::r--
> mask::r--
> other::r--
this is what i expected.
> This would introduce order dependencies on setting permissions, and lead
> to unexpected results for non-ACL-aware applications. The following two
> sequences of C commands would yield different ACLs on binary_file:
>
> fd = open("binary_file", O_CREAT, 0755);
> write(fd, buffer, size);
> fchmod(fd, 0755);
> close(fd);
in this example the fchmod call is unnecessary and redundant, and
would not break/change anything as i understand it.
> fd = open("binary_file", O_CREAT, 0644);
> write(fd, buffer, size);
> fchmod(fd, 0755);
> close(fd);
i would consider this code broken.
> One of the goals of POSIX ACLs is to retain compatibility with legacy
> POSIX systems as far as possible. This is why the first approach was
> chosen.
but you are only partially working around this alleged problem, since
if you say the fact that the webstats user above is getting execute
permissions is wrong, then it will still be left without execute
permissions after the above code examples perform chmod 755.
> Another benefit of this approach is that it's possible to have only one
> default ACL, for producing the desired permissions for files as well as
> for directories that are created. Other systems with POSIX-like ACLs have
> a default ACL for non-directories, and another default directory ACL. On
> those systems, non-directories inherit the default ACL, and directories
> inherit the default directory ACL.
that system seems more flexible.
>
> > looking at your examples the behavior im observing does indeed seem
> > anomalous, should i report this to the XFS folks?
>
> Yes, the example you gave does indeed look suspicious. I'm sure if your
> example is correct the XFS folks will fix this in no time :-)
>
> [Btw, I have corrected an error in <http://acl.bestbits.at/example.html>
> while writing this response...]
my problem with this is i am *extremely* picky about permissions, in
particular i believe that files should never ever have ANY execute
permission bits unless its really an executable, so the fact that
files are getting effectivly mode 654 instead of the correct 644
bothers me a great deal.
--
Ethan Benson
http://www.alaska.net/~erbenson/
pgpBSspzAIAAA.pgp
Description: PGP signature
|