On Fri, May 15, 2015 at 4:37 AM, Klaus Hartnegg <hartnegg at uni-freiburg.de> wrote:> Not sure which email you mean. I don't think that this can happen. If the > Linux acls are modified, the Windows ACLs are destroyed and all is based on > the Linux permissions and acls (which looks strange when viewed from > Window). If the Windows ACLs are modified, Samba automatically adjusts the > Linux acls accordingly. They should always be in sync. >Klaus, I think my test demonstrated what you are saying. I changed a share's permissions from root:root rwxrwxrwx to root:root rwxrwx--- And then the windows AD Administrator account was no longer able to access the share. If I made a linux user account on the server called "Administrator" and did: setfacl -R -m -u:Administrator:rwx /mnt/data then the Administrator would be configured using posix acl's for access to the share. I guess the moral of the story: if you don't want to setup AD domain users with linux user accounts on the server, and are serving shares only to windows clients - DON'T touch posix permissions or acl's. Use Microsoft ADUC and Samba4 will interpret/provide the acl settings to the linux filesystem. Is that close to correct?
Am 15.05.2015 um 16:20 schrieb Mike:> On Fri, May 15, 2015 at 4:37 AM, Klaus Hartnegg <hartnegg at uni-freiburg.de> > wrote: > >> Not sure which email you mean. I don't think that this can happen. If the >> Linux acls are modified, the Windows ACLs are destroyed and all is based on >> the Linux permissions and acls (which looks strange when viewed from >> Window). If the Windows ACLs are modified, Samba automatically adjusts the >> Linux acls accordingly. They should always be in sync. >> > > Klaus, > > I think my test demonstrated what you are saying. > I changed a share's permissions from root:root rwxrwxrwx to root:root > rwxrwx--- > And then the windows AD Administrator account was no longer able to access > the share. > If I made a linux user account on the server called "Administrator" and did: > > setfacl -R -m -u:Administrator:rwx /mnt/data > > then the Administrator would be configured using posix acl's for access to > the share. > > I guess the moral of the story: > > if you don't want to setup AD domain users with linux user accounts on the > server, and are serving shares only to windows clients - DON'T touch posix > permissions or acl's. Use Microsoft ADUC and Samba4 will interpret/provide > the acl settings to the linux filesystem. > > Is that close to correct?the real problem in that thread is that the ordinary chmod/chown permissions are called repeatly "acls" which is not wrong by the definiton of "access control list" but mixing that with "windows ACLs" and "posix ACLs" where on the FS layer we just have ACLs set with "setfacl" it leads to total confusion and nobody knows what people are talking about -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 181 bytes Desc: OpenPGP digital signature URL: <http://lists.samba.org/pipermail/samba/attachments/20150515/809d7421/attachment.pgp>
Greetings, Mike!>> Not sure which email you mean. I don't think that this can happen. If the >> Linux acls are modified, the Windows ACLs are destroyed and all is based on >> the Linux permissions and acls (which looks strange when viewed from >> Window). If the Windows ACLs are modified, Samba automatically adjusts the >> Linux acls accordingly. They should always be in sync. >>> Klaus,> I think my test demonstrated what you are saying. > I changed a share's permissions from root:root rwxrwxrwx to root:root > rwxrwx--- > And then the windows AD Administrator account was no longer able to access > the share. > If I made a linux user account on the server called "Administrator" and did:> setfacl -R -m -u:Administrator:rwx /mnt/data> then the Administrator would be configured using posix acl's for access to > the share.You don't even begin to understand the difference between ACL, POSIX access mask, user names and user ID's.> I guess the moral of the story:Moral of the story: You've compared apples to oranges and claimed that bananas are better.> Is that close to correct?That's not even relevant. When you've created a linux user called "Administrator" is had nothing to do with AD user "Administrator". When you changed POSIX access bits on a file it had very little to do with ACL. I... I just don't know how to explain it differently, than what had been said in a whole thread already. -- With best regards, Andrey Repin Friday, May 15, 2015 18:14:52 Sorry for my terrible english...
On Fri, May 15, 2015 at 10:30 AM, Reindl Harald <h.reindl at thelounge.net> wrote:> the real problem in that thread is that the ordinary chmod/chown > permissions are called repeatly "acls" which is not wrong by the definiton > of "access control list" but mixing that with "windows ACLs" and "posix > ACLs" where on the FS layer we just have ACLs set with "setfacl" it leads > to total confusion and nobody knows what people are talking about > > >Admitted. Access Control Lists extend the standard UNIX permission model in a POSIX compatible way. ACL supersedes the standard UNIX permission model. I've used the standard *nix permission model with local user accounts for so long that I can't seem to incorporate this new and separate ACL model. I need to drop concerns about *nix permission settings and think in ACL. Can't tell you how much I appreciate this group and list. Thank you, Mike
On Fri, May 15, 2015 at 11:24 AM, Andrey Repin <anrdaemon at yandex.ru> wrote:> Moral of the story: You've compared apples to oranges and claimed that > bananas > are better. > > When you've created a linux user called "Administrator" is had nothing to > do > with AD user "Administrator". > When you changed POSIX access bits on a file it had very little to do with > ACL. >Admitted. Per my last post, though, the difference is setting in. Thank you, Mike
Am 15.05.2015 um 16:30 schrieb Reindl Harald:> the real problem in that thread is that the ordinary chmod/chown > permissions are called repeatly "acls" which is not wrong by the > definiton of "access control list" but mixing that with "windows ACLs" > and "posix ACLs" where on the FS layer we just have ACLs set with > "setfacl" it leads to total confusion and nobody knows what people are > talking aboutLet's use the term access rights for a moment, to make sure that these points are absolutely clear: If the files on the server are mainly accessed through Samba, then it is usually better to use Windows to set all access rights. Samba will in this case adjust the Linux access rights such that they match the Windows access rights as closely as possible. In this case you do not need to care about Linux acls, just make sure that the file system supports them (and user-attrs), because Samba needs them. If access rights have been set from Windows, you should never try to use Linux to set different access rights for Linux users. Every modification done from Linux will erase the access rights that were set for this file or directory from Windows, even flipping just one bit, even changing the owner. Alternatively you can set all access rights in Linux. In this case you should use the samba option to disable the permissions tab in windows explorer. And you should learn Linux acls, because they are much more flexible than the old chmod bits for user-group-all. Linux uses acls in addition to the old permissions bits. The most irritating aspect of Linux-acls is that the bits shown by the "ls"-command for the group are replaced by the ones for acl-mask. This mas is a filter for all acl-rights. The group bits are still there, and in action, but "ls" cannot see them, and "chmod" cannot access them. The reason for this construct is that historically the usual method to temporarily lock everybody out of a directory is to clear the group bits. Redirecting group bit access to the acl-mask ensures that also all people are locked out who got access through an acl. Restoring the acl-mask also reactivates all acl-rights. Disturbing is the fact that one cannot simply do everything with Linux-acls, because there are always also the access rights of the owner. They are honoured before checking the acls. I do not know what to do if a user switches to a different team, and should loose the access rights to the old files. Windows does also know the concept of owner, and special permissions for that user, but such permissions are usually not set, and need not be set. hope this helps, Klaus