Question about parsing acl to get linux attributes.

Question about parsing acl to get linux attributes.

[Stef Bon]

Hi,

I'm working on a FUSE filesystem to browse and access SMB networks.
I'm using libsmb2 for that. It's not online yet, but my software is here:

https://github.com/stefbon/OSNS

Now I found out that smb2/3 do not support posix like file attributes,
but do (almost?) everything with acl's.
Now I see the function parse_dacl in fs/cifs/cifsacl.c, which
determines the permissions from the acl. I see also that when there
are no acl's, the default is 0777. I made the same choice in my
filesystem.
I've got some questions:

a. what does the sid_unix_NFS_mode stand for? Is it part of the "unix
extensions module for Windows"?

b. can you assume some order in the acl's, so you participate on that?
I want to know there are optimizations possible.

Thanks in advance,

Stef Bon

Re: Question about parsing acl to get linux attributes.

[ronnie sahlberg]

On Sun, Aug 1, 2021 at 2:02 AM Stef Bon <stefbon@gmail.com> wrote:
>
> Hi,
>
> I'm working on a FUSE filesystem to browse and access SMB networks.
> I'm using libsmb2 for that. It's not online yet, but my software is here:
>
> https://github.com/stefbon/OSNS
>
> Now I found out that smb2/3 do not support posix like file attributes,
> but do (almost?) everything with acl's.
> Now I see the function parse_dacl in fs/cifs/cifsacl.c, which
> determines the permissions from the acl. I see also that when there
> are no acl's, the default is 0777. I made the same choice in my
> filesystem.
> I've got some questions:
>
> a. what does the sid_unix_NFS_mode stand for? Is it part of the "unix
> extensions module for Windows"?
>
> b. can you assume some order in the acl's, so you participate on that?
> I want to know there are optimizations possible.

The ACE entries in the ACL are processed in order, thus a user can
create very sophisticated
ACLs by ordering the entries carefully.

The ACEs are actually processed twice when access is evaluated.
First it handles all the DENY ACEs. So it goes through the ACL, only
looking a the DENY ACEs and ignoring all other ACEs.

Once it has processed the entire ACL this way, and IF the user was not
denied access,
then it will go through the entire ACL a second time, this time only
looking at the ALLOW ACE entries to see
if the user is granted access.


Example:
1, S-1-2-ALICE                  ALLOW   READ
2, S-1-2-BOB                     ALLOW  READ/WRITE
3, S-1-2-EVERYBODY      ALLOW   READ/WRITE
4, S-1-2-BOB                     DENY     WRITE

In this case, even though there are two ACEs that would grant BOB
WRITE access (the ACE for BOB and EVERYBODY), BOB is still denied
write access due to the presence of a DENY ACE for WRITE.

In this case the ACEs are evaluated in the following order
4, 1, 2, 3

>
> Thanks in advance,
>
> Stef Bon

Re: Question about parsing acl to get linux attributes.

[Stef Bon]

Op za 31 jul. 2021 om 23:57 schreef ronnie sahlberg <ronniesahlberg@gmail.com>:
>
>
>
>
> Example:
> 1, S-1-2-ALICE                  ALLOW   READ
> 2, S-1-2-BOB                     ALLOW  READ/WRITE
> 3, S-1-2-EVERYBODY      ALLOW   READ/WRITE
> 4, S-1-2-BOB                     DENY     WRITE
>
> In this case, even though there are two ACEs that would grant BOB
> WRITE access (the ACE for BOB and EVERYBODY), BOB is still denied
> write access due to the presence of a DENY ACE for WRITE.
>
> In this case the ACEs are evaluated in the following order
> 4, 1, 2, 3

Wow this will take a lot of time to process when listing a directory.
After the readdir for every entry a lookup is done, for more details,
and then this processing of a list has to be done.

Is it really required to do this more than once? You mention looking
first for the denies, and then the allow entries. But what happens if
there no allow entries, then it will be denied I think. Is it
something like iptables: there is a default policy which counts when
no rule applies?
If this is the case you do not have to do it twice:
- if the policy is deny, you only have to look for allow rules
- and vica versa if the policy is allow, you will have to look for deny rules

Stef

PS it is sophisticated, but (I read somewhere) no system administrator
will use the fine grained rules, use defaults (which make them
predictable).

Re: Question about parsing acl to get linux attributes.

[ronnie sahlberg]

On Sun, Aug 1, 2021 at 2:12 PM Stef Bon <stefbon@gmail.com> wrote:
>
> Op za 31 jul. 2021 om 23:57 schreef ronnie sahlberg <ronniesahlberg@gmail.com>:
> >
> >
> >
> >
> > Example:
> > 1, S-1-2-ALICE                  ALLOW   READ
> > 2, S-1-2-BOB                     ALLOW  READ/WRITE
> > 3, S-1-2-EVERYBODY      ALLOW   READ/WRITE
> > 4, S-1-2-BOB                     DENY     WRITE
> >
> > In this case, even though there are two ACEs that would grant BOB
> > WRITE access (the ACE for BOB and EVERYBODY), BOB is still denied
> > write access due to the presence of a DENY ACE for WRITE.
> >
> > In this case the ACEs are evaluated in the following order
> > 4, 1, 2, 3
>
> Wow this will take a lot of time to process when listing a directory.
> After the readdir for every entry a lookup is done, for more details,
> and then this processing of a list has to be done.
>
> Is it really required to do this more than once? You mention looking
> first for the denies, and then the allow entries. But what happens if
> there no allow entries, then it will be denied I think. Is it
> something like iptables: there is a default policy which counts when
> no rule applies?

If there are no allow entres, then the access will be denied.

> If this is the case you do not have to do it twice:
> - if the policy is deny, you only have to look for allow rules
> - and vica versa if the policy is allow, you will have to look for deny rules

The point of checking the DENY entries first is to make sure that a
mistakenly too wide entry will not allow
unintended people access.
Or, for use cases where for example you want ALL users access, EXCEPT
for a special group, like a group where all temp contractors are
members of.
It also makes it less likely to make mistakes since you are not
dependent on the ordering of the ACEs.

And you could then do this with an ACL such as this:
1, S-1-2-EVERYONE                                    ALLOW   READ
2, S-1-2-NOT_FULL_TIME_EMPLOYEES   DENY      READ

This is a pretty common way to manage ACLs in large windows shares.
You have one entry that gives broad access   then a sharper entry that
excludes people.


So for correctness in a client, you would need to always check both.
But, you could take shortcuts. After all, the permissions you return
to the application
are just "cosmetics" for the application anyway.
Every access you do will be evaluated and enforced on the server anyway,
so if you get this mapping wrong (which will happen because it is
impossible to map an NTFS security descriptor onto a posix acl
perfectly for every corner case)  the worst thing this will lead to is
for example that you told the application "here is the acl, the acl
says you can read/..."  but once the application tries to do so it
gets ACCESS_DENIED back from the server, which may surprise the app.

So, clientside, it is not strictly that important to get the mapping
when reading an ACL perfect.
Writing the ACL on the other hand, that is where things get a lot more
complicated. For that case it is probably best to never write the ACL
from posix and only do it from the windows explorer, you know what
actual permissions are set.


Aside from the ACLs and mapping the ACEs into a posix ACL, you will
also need to think about how
uid mapping should work.
In NTFS/SMB you don't have uids/gids  instead you have SIDs.
There is no standard way on doing this type of mapping and there are
several different ways to do so, depending on
requirements. Even samba itself has multiple different ways you can do
this. And none of them are better than the other. They are all
different and imperfect due to the underlying differences in security
model.
For unix/windows integration, deciding on how and which type of
mapping to use is often very difficult and something that takes a lot
of work and preparations to decide on.

So for the process of usermapping, you need a method to map a
user/group SID into a unix uid/gid. You could do this yourself by just
creating a persistent database between SIDs that you encounter and
just assign them new uids as you discover the SIDs.
You could also use the LookupSIDs call in the libsmb2 dce/rpc
implementation. This is an RPC to the server that tries to resolve a
SID into an account/group name, and then you could instead have a
database that maps between names and uid/gid.
An easier path would be to use winbindd or sshd and have the Linux
system joined to the domain and then winbindd/sshd will do this
mapping for you.
But then you have an external dependency with a sometimes complex
configuration you have to set up first.


Don't get me wrong. But usermapping and translation between NT and
Posix ACLs is very complex. It is well worth doing if you want to
but it is a massive project.
I would personally just do something very simple like :
1, tell the application that the permissions are 0777 for everything, always
2, tell the application that the uid/gid is the same as the current
process, always
3, hope that most applications will deal with it gracefully. Most will.

(This just because I have worked in the smb fileserver space for a
long long time and doing full usermapping and acl translation could
well be a multi-person-year project.)

> Stef
>
> PS it is sophisticated, but (I read somewhere) no system administrator
> will use the fine grained rules, use defaults (which make them
> predictable).

They absolutely do. But they won't be setting these ACL for every
single file or directory.
From am admin standpoint you mostly set these controls on a directory
level and then flag the ACE entries to be inherited.
Those settings will then at runtime also apply to all files and
directories below that directory.

When reading ACLs from the server for an object, you will not have to
do these scans recursively, it is done for you.
So if you do a "get acl for /foo/bar/baz" then the server will check
the ACL for all three of foo, bar and baz and on demand compute
what the total ACL would be for baz, taking into consideration
inheritable ACEs from foo and bar.

Reading ACLs is a pretty expensive operation server side for this reason.
But it is rich   and very powerful.


Taking inheritance into account, it might not be uncommon for the
resulting ACL for files in a large environment to have hundreds or
even thousands of ACE entries.


regards
ronnie sahlberg