[linux-cifs-client] Windows ACL support

[Shirish Pargaonkar]

On 2/23/08, Martin Koeppe <mkoeppe at gmx.de> wrote:
>
> Hi all,
>
> I just wanted to post some information about Windows ACL to Unix
> owner, group and mode bits mapping, which I found out while using SFU
> and Server for NFS. I hope this info can be useful for
> designing/improving ACL support in linux-cifs, addressing TODO list
> item a).
>
>
> 1. NTFS features
> ----------------
> Files stored on a NTFS volume have an owner (saved as SID) AND a group
> (often named "primary group" in windows docs), also saved as a SID.
> This group info isn't shown in Explorer anywhere, but there is a tool,
> SubInACL.exe, which can display and change a file's GID-SID:
> http://www.microsoft.com/downloads/details.aspx?FamilyID=e8ba3e56-d8fe-4a91-93cf-ed6985e3927b&displaylang=en
> So it is possible to store Unix owner and group information on NTFS.
>
>
> 2. Mapping SIDs to UIDs and GIDs
> --------------------------------
> In MS SFU 3.5 or in Windows Server 2003 R2 there is an Server for NFS
> included, which exports NTFS folders for Unix NFS clients. This Server
> for NFS has the same problem of mapping Windows ACLs to Unix
> owner/group/mode as linux-cifs has.
> The mapping of the Windows SIDs used for owner and group on NTFS to
> the Unix numeric UID and GID can be done there by 2 different ways:
>
> The first (and older one) is User Name Mapping. This is a service
> which can be configured manually to map specific SIDs to the desired
> UID or GID. Server for NFS then queries this service to translate the
> SID to UID/GID and vice versa.
>
> The second is new with 2003 R2. If installed, the AD structure is
> enhanced to also store Unix UID info together with an AD user object
> resp. Unix GID together with an AD group object. This info then can
> alternatively be used for mapping by Server for NFS.
>
> Both of these services run on Windows, but may be connected to via
> network, so it should be possible to let linux-cifs use them.
>
> Interix (also part of SFU 3.5 or SUA 5.2 aka 2003R2) OTOH, i.e. the
> kernel subsystem letting e.g. bash run on windows, uses another way to
> map SIDs to UIDs and GIDs. It's not a configurable mapping, but
> instead an algorithmic way to extract some local (i.e. not related to
> the domain) number from the SID and take this as UID or GID. E.g. the
> local default Administrator user with the well-known SID
> S-1-5-Domain-500 maps to UID 197108. (In hex it is: S-1-5-...-1F4
> which maps to 301F4).
>
> Server for NFS isn't built on top of the Interix subsystem, so it
> doesn't use this algorithmic mapping. The UNM or AD method seems more
> reasonnable for linux-cifs purposes.
>
>
> 3. ACL to mode bit mapping
> --------------------------
> How the mode bits are calculated from ACLs I already wrote some time
> ago here:
> http://marc.info/?l=linux-cifs-client&m=111791448926374&w=2
>
> I now found also these pages:
> http://technet2.microsoft.com/windowsserver/en/library/d342b911-6d7f-432a-a992-230948510cfe1033.mspx?mfr=true
> http://blogs.msdn.com/sfu/archive/2007/05/11/how-user-name-mapping-works.aspx
>
> If the NFS server gets a request to list the mode bits for a file, it
> takes the file's owner Windows SID. Then it authenticates this SID,
> probably (I'm not sure here) getting a list of all Windows group SIDs
> back, where the user SID is member of. I'm not sure if obtaining such
> a list remotely is possible, but it would simplify (or make
> it possible) for linux-cifs to calculate the mode bits.
>
> It now processes the file's ACL and calculates the mode bits as
> described in my earlier posting, i.e. going though all ACEs and
> looking if they match one of the user's SIDs. The same is done for the
> file's group SID to get the group mode bits.
>
> When storing a new file, Server for NFS has 2 modes how the ACL can be
> set. The default mode is to only add those ACEs to the ACL that
> represent the owner and the group of the file, thus exactly what Unix
> would do. The other more interesting thing is a setting called
> "KeepInheritance". If activated, all inherited ACEs are preserved
> in addition to the just created ACEs. This can have the effect that
> users may have access to files where the mode bits wouldn't permit
> access.
>
> Example: a file's owner is user A, group is G. The ACEs let A
> and G have rwx rights to the file resulting in mode bits -rwxrwx---.
> Now take another user B which is in group H, but not in G. In the Unix
> world he couldn't access the file. But with KeepInheritance on, there
> may be an inherited ACE which grants access to B or H, thus B may be
> able to read the file. So it's possible to make use of the more
> flexible Windows ACLs from within Unix.
>
> This may be useful for linux-cifs also: A SMB session is created for
> one user C mounting the share. The files on the share may have
> different owners/groups, say D/H and E/K. When listing files from such
> a share via linux-cifs, it could look as follows:
>
> -rwxrwx---  D  H   file1
> -rwxrwx---  E  K   file2
>
> Nevertheless linux-cifs should not block an access to one of these
> files, as there may be additional ACEs granting access to C,
> which cannot expressed via the mode bits.
>
>
> 4. Sym Links
> ------------
> This posting shouldn't be about symlinks, but I just read this recent
> posting from Steve:
>
> > It would be possible for cifs to create symlinks as SUA (Windows
> > Services for Unix) does, since it can read them (although they are
> > often in a useless format with drive letters in the path) but it
> > would need minor changes to write such a feature for servers which
> > do not support the Unix Extensions.
>
> This is not quite right. SFU/SUA symlinks store the Unix-like file
> names, so they never contain drive letters! Server for NFS and Interix
> kernel subsystem use the same format (a system file beginning with
> "IntxLNK") to store the link target, in Unix format, e.g. a link
> L -> /usr/local/tmp/posix:\valid*file?name
> is stored exactly in this way, i.e. the Unix path and unix file name,
> even though some of the file name characters are not valid windows
> file name characters. It is stored in Unicode though.
>
> When the link is then followed, then the Unix file name to look up is
> first translated to valid windows file names, i.e. adding 0xf000 to
> all these ASCII chars [:\*?] which aren't valid for Windows.
>
> So linux-cifs should not translate any symlink content wrt. drive
> letters etc. besides from simply convert Unicode to ASCII. Only when
> real file names are asked for, they need to be translated first with
> +0xf000 before asking the SMB server.
>
>
> I can do further tests with Server for NFS, Interix or linux-cifs if
> required.
>
> Martin
> _______________________________________________
> linux-cifs-client mailing list
> linux-cifs-client at lists.samba.org
> https://lists.samba.org/mailman/listinfo/linux-cifs-client
>

Martin,

I am not sure if you have looked at the latest cifs client code but there is an
attempt to map NTFS ACLs to Unix mode bits and vice versa.
It is still experimental code and lots of room for improvement and correction
like ACE inheritance as you mentioned.

The ACLs to mode bit conversion algorithm currently does not take into account
two other types of ACEs, allowed object and denied object.
And this page lists the algorithm Microsoft uses in ACL to UNIX permissions
conversion (Windows to UNIX Mapping)
http://technet.microsoft.com/en-us/library/bb463216.aspx#ECAA

To map SIDs to UID and GID,  one way could be to use winbind which already
does that work.  An upcall needs to be implemented to talk to a cifs
utility which
interacts with windbind via winbind's APIs to resolve SID and GID.  And winbind
can be used withing nfsswitch.conf.  Otherwise all that work, making itself
available in nfsswitch.conf, maintining mappings (SID to UID and SID to GID
and vice versa), and discovering mappings (via LSA protocol?) has to be done
by cifs client.

Beyond mapping ACLs to UNIX permission mode, I think ACLs need to be
mapped to POSIX ACLs as well NFSv4 ACLs as well.