View Incident:
http://co-op.engr.sgi.com/BugWorks/code/bwxquery.cgi?search=Search&wlong=1&view_type=Bug&wi=820248
Submitter : tes Submitter Domain : engr
Assigned Engineer : tes Assigned Domain : engr
Assigned Group : xfs-linux Category : software
Customer Reported : F Priority : 3
Project : xfs-linux Status : open
Description :
Bug discovered by jtrostel@xxxxxxxxxxx
Basically the umask is being used in the case where
the default ACL should be used.
Bugifying the email :)
========================================
Date: Thu, 29 Mar 2001 17:40:57 +0200
From: Carlos Gamboa Dos Santos <Carlos.Gamboa@xxxxxx>
To: Andrew Gildfind <ajag@xxxxxxxxxxxxxxxxxxxxxxx>
CC: linux-xfs@xxxxxxxxxxx
Subject: Re: Problems with ACL inheritance and chacl
Hi...
Andrew Gildfind wrote:
>
> On Tue, Mar 27, 2001 at 10:51:42AM -0500, John Trostel wrote:
> > I am seeing some strange behavior with both ACL inheritance and chacl
> > operation. Does anyone else see this or is my build faulty?
> >
> > I started with a freshly formatted xfs partition on /mnt/xfs_part.
> >
> > I set the access, default and mask ACLs for this parition as follows:
> >
> > [...]
> >
> > Not good... Shouldn't this get the default ACLs u::rwx,g::rwx,o::rwx ?
>
> I'm not precisely sure of the semantics of ACL inheritance, but I noticed
> when playing around with this that the inherited ACL was modified by
> different umasks... I'll have to look into this further.
We saw the same behaviour with our builts. After a few tests, we confirmed that
"umask" was changing the active mask of the ACL and therefore limiting the real
accesses.
But... shouldn't "umask" be ignored in ACL where a mask is present?
Otherwise it seems that the flexibility of the ACLs is lost...
==============================================================
====================================================
To: John Trostel <jtrostel@xxxxxxxxxx>
Subject: Re: Problems with ACL inheritance and chacl & maybe a BUG
From: Timothy Shimmin <tes@xxxxxxxxxxxxxxxxxxxxxxx>
Date: Tue, 3 Apr 2001 17:47:55 +1000
Hi,
After looking at the Revised section 5 in the withdrawn
ACL standard, 5.3.1.2 states how a newly created file will
obtain its ACLs.
And indeed, if the ACLs are turned on and a file is created
in a directory which has a default ACL, then the umask
is not supposed to be used at all - only the default ACL and
the operation's mode are to be used.
The rational for this is given in section B.23.5 where it
actually explicitly says that the umask is not to be used.
Looking at the code in fs/xfs/xfs_acl.c and xfs_acl_inherit()
it is doing the right thing.
However, by this stage of setting up the acl the vap->va_mode
has already been changed by the umask !
So there is our bug.
In fs/namei.c (vfs_create(), vfs_mknod() and vfs_mkdir())
it updates the mode with the umask (before we get to see the
mode argument).
There needs to be a test on the directory to see if it
has a default ACL before updating the mode with the umask.
Looking at Andreas' ACL patch, he has in fact patched fs/namei.c
for each case of where umask is used.
If the inode's fs has ACLs turned on
(inode)->i_sb->s_ext_attr_flags & EXT_ATTR_FLAG_POSIX_ACL
then he doesn't use the umask.
Then in the ACL code, he uses the umask if the directory
doesn't have a default ACL.
============================================
Plan to do a similar fix as Andreas G. did.
|