ACCESS_DENIED ACL to POSIX Perms conversion.

[Kenny Dinh]

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)

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



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

> On Tue, Feb 10, 2015 at 06:01:44PM -0500, John Mulligan wrote:
> >
> > 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.
>
> Ah, I remember that bug - thanks for jogging my memory.
>
> Unfortunately making Samba work on top of filesystems
> with no ACLs is somewhat of a low priority - I'm not
> sure we can do it to fail safely in any case.
>
> I think the approach I suggested in the other email
> would work, although for security reasons I don't
> think we can use that upstream.
>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: image.png
Type: image/png
Size: 49082 bytes
Desc: not available
URL: <http://lists.samba.org/pipermail/samba-technical/attachments/20150210/5a9a108c/attachment.png>