linux-cifs.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: ronnie sahlberg <ronniesahlberg@gmail.com>
To: Stef Bon <stefbon@gmail.com>
Cc: linux-cifs <linux-cifs@vger.kernel.org>
Subject: Re: Question about parsing acl to get linux attributes.
Date: Sun, 1 Aug 2021 16:02:26 +1000	[thread overview]
Message-ID: <CAN05THQiDaAtCKFoem703U9FRkN-f+x69u26pPWmbh5QZVWFVw@mail.gmail.com> (raw)
In-Reply-To: <CANXojczOzWWebVJNDmS-b=cYSFOJ=0dSNSeNJ6T5+-FZfq_pNQ@mail.gmail.com>

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

      reply	other threads:[~2021-08-01  6:02 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-07-31 16:02 Question about parsing acl to get linux attributes Stef Bon
2021-07-31 21:57 ` ronnie sahlberg
2021-08-01  4:12   ` Stef Bon
2021-08-01  6:02     ` ronnie sahlberg [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAN05THQiDaAtCKFoem703U9FRkN-f+x69u26pPWmbh5QZVWFVw@mail.gmail.com \
    --to=ronniesahlberg@gmail.com \
    --cc=linux-cifs@vger.kernel.org \
    --cc=stefbon@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).