ACCESS_DENIED ACL to POSIX Perms conversion.
kdinh at peaxy.net
Tue Feb 10 15:58:23 MST 2015
Our FUSE file system return ENOTSUP when responding to
The bug I described is in SAMBA's fall back logic. When the code reached
the POSIX fall back logic (within SAMBA's source3/smbd/posix_acls.c),
there are too many ACEs in the list. The extra ACEs were added in the two
sub-functions I mentioned,
"create_canon_ace_list" and "ensure_canon_entry_valid_on_set".
On Tue, Feb 10, 2015 at 2:52 PM, John Mulligan <
phlogistonjohnjohn at asynchrono.us> wrote:
> On Tuesday, February 10, 2015 02:33:41 PM Jeremy Allison wrote:
> > On Tue, Feb 10, 2015 at 02:12:10PM -0800, Kenny Dinh wrote:
> > > Hello,
> > >
> > > We have a configuration where SAMBA sits in front of our FUSE file
> > > Our file system does not support ACL. We notice that when a Windows
> > > modifies security of a file, an ACCESS_DENIED is returned. Following
> > > code in source3/smbd/posix_acls.c, the function "set_nt_acl" calls
> > > "unpack_canon_ace" to convert Windows ACE format into canonical ACE
> > > format. The call eventually calls two other sub-functions
> > > "create_canon_ace_list" and "ensure_canon_entry_valid_on_set". Both of
> > > the
> > > two sub-functions, ended up adding additional ACEs to the ACL. When
> > > set_nt_acl function failed to process the ACL, the fall-back path is to
> > > try
> > > to convert ACL to POSIX permission. Because the ACL now has more than
> > > ACEs, the coversion failed with ACCESS_DENIED.
> > >
> > > Attached is my attempt to fix the issue. I created a copy of the
> > > descriptor and used it to in the fall-back path. I added a flag to
> > > prevent
> > > any new entries from being added to the original ACL.
> > >
> > > Could someone verify if this is the correct fix and push the change if
> > No, it isn't the correct fix I'm afraid.
> > If your file system doesn't support ACLs, the
> > correct thing to do is to return ENOSYS or
> > ENOTSUP when a call into SMB_VFS_SYS_ACL_SET_FILE()
> > or any of the other sys_acl_XXX() Samba
> > VFS functions are called.
> > Samba will then fall back correctly to
> > using 3-element permissions ('correctly'
> > meaning as best it can :-).
> I didn't read the whole patch but at least part of what Kenny is describing
> seems to overlap with this bug I filed a while back:
> I worked around our issue for the time being, but the last time I looked
> 4.1 was unable to generate the 3-element perms in any test case I tried.
> When I took a stab at it the "adding additional ACEs to the ACL" was surely
> involved in the problem. Somehow the conversion code gets to a point where
> there were too many aces, and for a lack of a better word, gives up.
> Unfortunately it was not a high priority for me and I didn't keep on
More information about the samba-technical