samba - May 2015 - Posix vs. Windows File/Directory Permissions

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 about
Let'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