ACCESS_DENIED ACL to POSIX Perms conversion.

[Kenny Dinh]

Jeremy,

Our FUSE file system return ENOTSUP when responding to
SMB_VFS_SYS_ALC_SET_FILE().

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".

Thanks,
Kenny



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
> system.
> > > Our file system does not support ACL.  We notice that when a Windows
> user
> > > modifies security of a file, an ACCESS_DENIED is returned.  Following
> the
> > > 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
> 3
> > > ACEs, the coversion failed with ACCESS_DENIED.
> > >
> > > Attached is my attempt to fix the issue.  I created a copy of the
> security
> > > 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
> it
> >
> > 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:
> https://bugzilla.samba.org/show_bug.cgi?id=10489
>
> I worked around our issue for the time being, but the last time I looked
> Samba
> 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
> debugging
> it.
>