[linux-cifs-client] patch to modify how ACEs are set for a chmod
command
Shirish Pargaonkar
shirishpargaonkar at gmail.com
Thu Jan 31 04:21:22 GMT 2008
On Jan 30, 2008 3:22 PM, simo <idra at samba.org> wrote:
>
>
> On Wed, 2008-01-30 at 12:35 -0600, Shirish Pargaonkar wrote:
> > Change the behaviour on what ACL is sent for a chmod command.
> > Instead of sending just three ACE, one for owner, one for group, and
> > one for everyone thus destroying any aces that existed on the object
> > on the server, this patch will now send those three aces and any
> > aces that existed as it is.
>
> Shirish,
> this is delicate matter, the problem is that changing semantics may have
> an impact on security.
>
> In POSIX the group permissions are aliased to a mask when POSIX ACLs are
> present. This means that if you do a chmod 600 myfile, even with posix
> ACLs the only one that will be allowed to access the file will be the
> user, no matter how many other users or groups are listed in the ACL.
>
> With your patch this does not hold true anymore, anyone with explicit
> access in the NT ACL will keep permission to access the file, only the
> user's primary group members and anyone else will be denied access.
>
> This is probably not what the user meant by setting the file to 600,
> usually what is meant is that the final result will be that only the
> user will have access.
>
> Now, getting an ACE list which represent this is definitely tricky and I
> guess that is why the current code simply wipes out the ACL completely
> and replaces it.
>
> A more sensible way would probably be to set the group bits for the
> primary group if no other ACEs are present, and instead to "mask" all
> other ACEs with the group bits if entries other than user/group/everyone
> are present. The downside of masking is that this would have a tattoo
> effect you do not have with POSIX ACLs.
>
> Another (more difficult and dangerous) way would be to use DENY ACEs to
> reverse a lack of access granted by the mask, but it would then get even
> trickier to understand if an existing DENY ACE was there because of a
> "mask" operation or was there before and should be preserved when, later
> on, someone decides to chmod 660 again.
>
> Tough call.
>
> Simo.
>
> --
> Simo Sorce
> Samba Team GPL Compliance Officer <simo at samba.org>
> Senior Software Engineer at Red Hat Inc. <ssorce at redhat.com>
>
> _______________________________________________
> linux-cifs-client mailing list
> linux-cifs-client at lists.samba.org
> https://lists.samba.org/mailman/listinfo/linux-cifs-client
>
Some of the questions:
I can add any of the following object types - User, Group, or Built-in
security prinicplas - to the access control list of this file object.
This object that gets added to the access control list of the file object
may or may not belong to Group of this file object.
If an User object belongs to the Group of file object, then group permissons
in the chmod apply (i.e. I would generate an access mask in
that ace corrosponding to the group permission bits in the chmod command).
If an User object does not belong to the Group of the file object, then other
permissons in the chmod apply (i.e. I would generate an access mask in
that ace corrosponding to the other permission bits in the chmod command).
Group or Built-in principal objects presumably do not belong to the Group
of the file object, so should they then be considered belonging to other and
other permissions of chmod apply?
But then how do you figure out whether an User object belongs to a
Group object? We have access to ACE of that User object, does it have
enough information to figure out its Group (SID)?
So even if we decide to mask an ACE which does not belong to
User, Group, and Other, which bits should be used as a mask,
group permission bits or other permission bits?
It is also possible that there is no ACE for Group SID in that
file object to begin with. So in response to the chmod command, should
then an ACE be created with appropriate access mask corropsonding to
the group bits in the chmod command?
BTW, in Windows, how do I view the Group of an object such as a file object?
I can view current Owner of this file object but not sure how to view
the Group.
I resorted to wireshark trace and psgetsid utility/command to find out
Group SID and figure out Group name respectively.
More information about the linux-cifs-client
mailing list