Bug 4875 - Setting ACLs with smbcacls cause wrong sort order
Summary: Setting ACLs with smbcacls cause wrong sort order
Status: NEW
Alias: None
Product: Samba 3.0
Classification: Unclassified
Component: Client Tools (show other bugs)
Version: 3.0.25b
Hardware: x86 Windows XP
: P3 major
Target Milestone: none
Assignee: Samba Bugzilla Account
QA Contact: Samba QA Contact
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2007-08-11 06:00 UTC by Henrik (dead mail address)
Modified: 2024-04-11 00:03 UTC (History)
2 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Henrik (dead mail address) 2007-08-11 06:00:07 UTC
When using smbcacls to restore acls on files residing on a windows
fileshare the acls are not sorted according to Windows Explorers security
interface.

If we try to view the security properties after setting acls with smbc_xattr we
get the following error 

"The permissions on 'Foo' are incorrectly ordered, which may cause some entries
to be ineffective. Press OK to continue and sort the permissions correctly, or
Cancel to reset the permissions."

Regards,
Henrik
Comment 1 Tucker Cunningham (dead mail address) 2007-10-16 18:21:26 UTC
a couple of comments to provide more information and bump this bug.

a) it would be nice if the -a syntax could add an ACL in the correct position in the list, but it is understandable if this is difficult
(note: see bug 2347)

b) however, the -S syntax is also broken.  it seems that -S should never have this problem because the user is providing the full, ordered ACL list.  it seems to me that doing 'smbcacls //server/share file' and reformatting the output into 'smbcacls //server/share file -S ...' should be a no-op.  in fact, it is reordering the ACLs to turn a correctly ordered list into an invalid list.
Comment 2 Tucker Cunningham (dead mail address) 2007-10-16 18:23:04 UTC
sorry, bug 2397 not 2347 (In reply to comment #1)

> in the list, but it is understandable if this is difficult
> (note: see bug 2347)