ACCESS_DENIED ACL to POSIX Perms conversion.

[Kenny Dinh]

Attached is the level 10 log.  If you search "set_nt_acl", you will find
the entry of function where the operation begins.

"Ah I see. But isn't that still going to fail
against your FUSE filesystem that doesn't allow
more than u/g/o"
Yes, the request will fail if the user sends an ACL that does not have
exactly u/g/o.

What I wanted the code to do was trying to make the "best effort" in the
fall back logic.
Since the back end does not support POSIX ACLs, and IFF there are exactly
u/g/o ACEs in the DACL,
I would attempt to translate the permissions.

It is clear to me now that this 'hack' applies only a very limited set of
use case.

Thanks again for your time, Jeremy!


On Tue, Feb 10, 2015 at 9:03 PM, Jeremy Allison <jra at samba.org> wrote:

> On Tue, Feb 10, 2015 at 05:30:34PM -0800, Kenny Dinh wrote:
> > Jeremy,
> >
> > Thank you for reviewing.  Since this issue is low priority, I apologize
> for
> > taking a little more of your time.
> > I understood your suggestions and will explore those paths.  Due to
> > security reason, I understood that
> > the patch should not get pushed upstream.
> > For the sake of discussion, I just want to clarify a few points before
> > ending the thread.
> >
> > 1) Yes, the check in "convert_canon_ace_to_posix_perms" is where I
> > encountered the error.
> >  However, the extra entries were added by SAMBA.  Windows user sent only
> 3
> > ACEs, but the
> >  two functions I mentioned earlier, "create_canon_ace_list" and
> > "ensure_canon_entry_valid_on_set"
> >  added 2 additional ACEs.
> > The attached snapshot of Wireshark show the requests being sent with 3
> ACEs.
> >
> > [image: Inline image 1]
> >
> > However, in the log file, two new ACEs were added, canon_ace index 1
> > (SMB_ACL_USER), and 4(SMB_ACL_GROUP)
>
> Yeah, but that can happen for correctness. I'd need
> to see a debug level 10 log to see what Windows wanted
> to understand why we added the 2 extra entries.
>
> Might be a winbindd doing a user+group addition
> as we have to map groups to users also sometimes in order
> to allow files to appear to be owned by a group.
>
> > [2015/02/10 17:04:37.201078, 10, pid=22591, effective(10500, 10513),
> > real(10500, 0), class=acls]
> > ../source3/smbd/posix_acls.c:848(print_canon_ace_list)
> >   print_canon_ace_list: file ace - before merge
> >   canon_ace index 0. Type = allow SID = S-1-1-0 other SMB_ACL_OTHER
> > ace_flags = 0x0 perms rwx
> >   canon_ace index 1. Type = allow SID =
> > S-1-5-21-4189473893-3250479902-1333435561-1110 uid 11110 (testgroup1)
> > SMB_ACL_USER ace_flags = 0x0 perms r--
> >   canon_ace index 2. Type = allow SID =
> > S-1-5-21-4189473893-3250479902-1333435561-1110 gid 11110 (testgroup1)
> > SMB_ACL_GROUP_OBJ ace_flags = 0x0 perms r--
> >   canon_ace index 3. Type = allow SID =
> > S-1-5-21-4189473893-3250479902-1333435561-500 uid 10500 (administrator)
> > SMB_ACL_USER_OBJ ace_flags = 0x0 perms rwx
> >   canon_ace index 4. Type = allow SID =
> > S-1-5-21-4189473893-3250479902-1333435561-500 gid 10500 (administrator)
> > SMB_ACL_GROUP ace_flags = 0x0 perms rwx
> > [2015/02/10 17:04:37.206550, 10, pid=22591, effective(10500, 10513),
> > real(10500, 0), class=acls]
> > ../source3/smbd/posix_acls.c:848(print_canon_ace_list)
> > "
> >
> > 2)  "simply strips out everything except u/g/o
> > permissions" - Not entirely correct.  The code only strip out the extra
> > entries that were added
> > by  "create_canon_ace_list" and "ensure_canon_entry_valid_on_set".
> > Essentially, preventing
> > the addition canon_ace index 1, and 4, from being added.  Each ACE is set
> > with SMB_ACL_USER_OBJ,
> > or SMB_ACL_GROUP_OBJ, depends on whether the SID represents a user or a
> > group.
> > All ACEs that Windows client sent are preserved.  If client send 4 ACEs,
> > "convert_canon_ace_to_posix_perms" will see 4 ACEs.
> >
> > Hope this clarify things a bit.
>
> Ah I see. But isn't that still going to fail
> against your FUSE filesystem that doesn't allow
> more than u/g/o ?
>
> What do you *want* this code to do for you ?
>
> Jeremy.
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: log.172.16.35.zip
Type: application/zip
Size: 142101 bytes
Desc: not available
URL: <http://lists.samba.org/pipermail/samba-technical/attachments/20150210/25988af8/attachment-0001.zip>