How to get permissions based on supplementary groups?
Corinna Vinschen
I have set up multiple Windows machines (the OS doesn't matter, I have
the same problem on XP, Vista, 2008, and W7) with NFS client to access
NFS shares under Linux. The user name mapping is via my Windows 2008
domain. The user and group entries in AD utilize the uid and gid
settings per RFC 2307.
Consider this scenario:
- My Windows account "corinna" maps to uid 500, which is the uid of the
account "corinna" on the Linux box.
- My Windows primary group "vinschen" maps to gid 100, which is the gid
of group "vinschen" on the Linux box.
- The Windows group "suppl" maps to gid 111, which is the gid of the
group "suppl" on the Linux box.
- The account "corinna" is member in the group "suppl".
- There's a share //linux-box/share
owner uid 0 (root), group gid 0 (root), perms rwxr-xr-x
- There's a subdirectory //linux-box/share/subdir
owner uid 12345 (irrelevant), group gid 111 (suppl), perms rwxrws---
As you can see, the permissions on subdir only allow access from
accounts being member of the "suppl" group.
When I access this NFS share from another Linux box, I can do this
without problems. I can access files in //linux-box/share, and I can cd
to subdir and read and write files there, as expected, since group 111
is in my supplementary group list.
When I access this NFS share from my Windows clients I can access
//linux-box/share just fine, but I get a "Permission denied" message
when trying to access subdir.
I checked that my user token contains the Windows group "suppl".
I also checked in AD that the group "suppl" has set the UNIX attributes
as desired (gid 111, the members list shows the account "corinna" as
member of the group).
Since my user token's group list contains the "suppl" entry, and since
the "suppl" group maps to gid 111, shouldn't gid 111 be in my
supplementary group list and shouldn't I have access to subdir from
Windows the same way as from another Linux box?
However, even the Explorer GUI doesn't show any supplementary group.
When I open the "Properties" dialog of //linux-box/share and switch to
the "NFS Mount Options" tab, the "Secondary GIDs" drop-down menu is
empty.
So, here's the question.
Why is the group "suppl" missing in my Secondary GIDs list, and what
do I have to do to fill my Secondary GIDs list with the desired groups,
so that I can access folders like the above "subdir"?
Thanks in advance,
Corinna
--
Corinna Vinschen
Cygwin Project Co-Leader
Red Hat
Ashish
map. Do you have this information present in the group file/map?
This will not work if you are using AD Lookup feature. The RFC2307
doesn't define how to store supplementary group information on a user
object and it is not practical to enumerate all the groups and find
out what supplementary group membership a user has. This information
can be changed dynamically so caching or polling can be unrealiable.
- Ashish
Corinna Vinschen
> UNM service fetches this information from the group file or group NIS
> map. Do you have this information present in the group file/map?
I don't have a NIS setup. The Linux machines use local /etc/passwd,
/etc/group based authentication.
> This will not work if you are using AD Lookup feature. The RFC2307
Oh well.
> doesn't define how to store supplementary group information on a user
> object and it is not practical to enumerate all the groups and find
> out what supplementary group membership a user has. This information
> can be changed dynamically so caching or polling can be unrealiable.
I don't understand the problem.
If I logon to a Linux machine, the supplementary group list of my user
account is set once, exactly at logon time. Apart from explicit usage
of initgroups(2) or setgroups(2), which are privileged calls anyway, the
list is fixed for the lifetime of the user session. Changes in the
user/group database don't change anything in a running session.
If I logon on Windows machine, the user token's group list if my user
account is set once, exactly at logon time. While the supplementary
Windows groups can be dropped from subsequent restricted tokens, the
list is basically as fixed for the lifetime of the user session as on
Linux.
So, what's the problem of caching the Windows group to gid mapping
over the lifetime of a user session?
Ashish
same group file that is on your *nix box - it will work. The XP client
doesn't support AD Lookup.
On the AD Lookup thing - In AD, the group membership information is
stored on the user objects and similarly, the group store the
information about members. The RFC2307 doesn't provide any mechanism
where we can store information about users' secondary group
membership. If we leave apart the runtime updates to this information
and want to cache this information when the user session begins - we
will have to enumerate every group object in the domain to see if this
user is member of it. It will work in a in a test lab, with a few
users but, in bigger environments, it will only degrade the
performance.
And, CNFS doesn't use AD group memberships to determine the group - it
uses the RFC2307 attribute gidNumber to determine the primary group of
user for NFS requests.
- Ashish
Matt Seitz
"Ashish" <ash...@gmail.com> wrote in message
news:2db38bd1-ce56-45de...@l35g2000pra.googlegroups.com...
>The RFC2307 doesn't provide any mechanism
> where we can store information about users' secondary group
> membership.
Could you use this?
( nisSchema.2.2 NAME 'posixGroup' SUP top STRUCTURAL
DESC 'Abstraction of a group of accounts'
MUST ( cn $ gidNumber )
MAY ( userPassword $ memberUid $ description ) )
> we
> will have to enumerate every group object in the domain to see if this
> user is member of it. It will work in a in a test lab, with a few
> users but, in bigger environments, it will only degrade the
> performance.
How does a POSIX machine determine a user's secondary group membership?
If performance is an issue, could you give the user the option whether or not to
enable it?
Corinna Vinschen
> "Ashish" <ash...@gmail.com> wrote in message
> news:2db38bd1-ce56-45de...@l35g2000pra.googlegroups.com...
>>The RFC2307 doesn't provide any mechanism
>> where we can store information about users' secondary group
>> membership.
But the information exists in AD, one way or the other. It's surprising
that it's not just used to create the user information.
> Could you use this?
>
> ( nisSchema.2.2 NAME 'posixGroup' SUP top STRUCTURAL
> DESC 'Abstraction of a group of accounts'
> MUST ( cn $ gidNumber )
> MAY ( userPassword $ memberUid $ description ) )
I don't understand this one...
>> we
>> will have to enumerate every group object in the domain to see if this
>> user is member of it. It will work in a in a test lab, with a few
>> users but, in bigger environments, it will only degrade the
>> performance.
>
> How does a POSIX machine determine a user's secondary group membership?
If authentication is based on /etc/passwd and /etc/group files, the
supplementary group list is created by enumerating all groups in
/etc/group and examining the gr_mem field for the list of users which
are member of the group. If authentication is LDAP based, the POSIX
system would have to do the same via the LDAP request per RFC 2307.
So, basically, it's the exact same job, regardless whether it's a
POSIX system or a Windows system.
> If performance is an issue, could you give the user the option whether or not to
> enable it?
That would be cool. But given that the list has to be created only once
per session, I'm wondering if that's really such a big hit.
Matt Seitz
"Corinna Vinschen" <cor...@community.nospam> wrote in message
news:h6gf6q$h4e$1...@perth.hirmke.de...
> Matt Seitz wrote:
>> "Ashish" <ash...@gmail.com> wrote in message
>> news:2db38bd1-ce56-45de...@l35g2000pra.googlegroups.com...
>>>The RFC2307 doesn't provide any mechanism
>>> where we can store information about users' secondary group
>>> membership.
>
>
>>
>> ( nisSchema.2.2 NAME 'posixGroup' SUP top STRUCTURAL
>> DESC 'Abstraction of a group of accounts'
>> MUST ( cn $ gidNumber )
>> MAY ( userPassword $ memberUid $ description ) )
>
> I don't understand this one...
I got that from RFC2307, thinking it was the approved schema for storing group
membership information in RFC2307 format.
Ashish
objects in AD to to be able to populate POSIX information on a group
object. All such group objects have to be enumerated to find out the
secondary group membership of users.
On a *nix system, the logon process takes care of this information and
as a result the secondary group information is available throughout
the logon session. There's an equivalent of this in AD but since AD
group membership is maintained on user objects and group objects as
well using backlinked attributes - it can be calculated on runtime and
there's no real need to cache this information. I don't know if it is
cached or not cached really.
The NFS redirector on Windows loads early during boot up as a kernel
driver and is independent of user logons (like it is on *nix systems)
but unlike *nix system where secondary group information is available
and is used (NFS originally was designed for *nix systems) - on a
Windows box - this information needs to be fetched whenever NFS access
occurs. RFC2307 doesn't define a mechanism that allows to use the
existing AD membership information or use backlinked attributes to get
it quickly when required.
If we want to cache this information - we cannot have a kernel mode
driver do this and we cannot do this at NFS access since that'll
increase the NFS access time (for the first time, if cache it then)
and every time we have to build the cache.
If you take example of MS NIS implementation - that uses
msSFU30PosixMemberOf attribute on a user object and msSFU30PosixMember
(which is backlinked with msSFU30PosixMemberOf) and memberUid
attributes for compatibility. It builds a cache to use but since the
information is available with backlinked attributes - there's not
performance hit when building the cache.
I don't know RFC2307 support is implemented on other Windows-based NFS
servers and how do they address this problem.
- Ashish
Corinna Vinschen
> If you take example of MS NIS implementation - that uses
> msSFU30PosixMemberOf attribute on a user object and msSFU30PosixMember
> (which is backlinked with msSFU30PosixMemberOf) and memberUid
> attributes for compatibility. It builds a cache to use but since the
> information is available with backlinked attributes - there's not
> performance hit when building the cache.
I just looked again, the msSFU30PosixMember attribute is filled in the
affected group in my AD, but for some reason the msSFU30PosixMemberOf
attribute of the user doesn't exist.
Apart from that, I'm wondering why the NFS client doesn't use the same
attributes when using AD identity mapping, rather than NIS name mapping?
That would allow to get supplementary groups regardless of the name
mapping mechanism.
Matt Seitz
>
> ...we cannot [fetch secondary group information] at NFS access since that'll
> increase the NFS access time (for the first time, if cache it then)
> and every time we have to build the cache.
Could you make fetching secondary group information optional, so that each user
can decide whether fast access time or secondary group information is more
important for them?
> I don't know RFC2307 support is implemented on other Windows-based NFS
> servers and how do they address this problem.
Is it the NFS server or the NFS client that provides the secondary group
information?
Ashish
Regardless, that attribute is part of the schema extension that MS
used for NIS implementation. It's not standard. NIS protocol has been
retired and people are bound to go away from NIS so this may get
removed from AD schema so it would not be a good strategy.
- Ashish
Ashish
server need to process this information to validate access and NFS
client provides the information but doesn't generate it itself -
another reason it has not been implemented in MS NFS client.
I hope this would be taken care of when the NFS v4 is implemented. For
now, using UNM can help but not sure how long people will run W2K3
servers.
- Ashish
Corinna Vinschen
> Did you use IdMU tools to populate this group with members?
I don't know what you mean with "IdMU". I simply used the Windows 2008
"Active Directory Users and Computers" MMC snap-in to generate these
entries. If ypu open the group properties dialog and switch to the tab
"UNIX Attributes", there's a "Members" list which can be populated
manually using the "Add..." button. Unfortunately it didn't help.
> Regardless, that attribute is part of the schema extension that MS
> used for NIS implementation. It's not standard. NIS protocol has been
> retired and people are bound to go away from NIS so this may get
> removed from AD schema so it would not be a good strategy.
Now, that's progress!
- Up to SFU 3.5 the name mapping was able to use /etc/passwd and
/etc/group files which allowed to specify supplementary groups.
- Starting with Vista we only have NFS and AD, and you say NIS name
mapping is the only one able to deal with supplementary groups when
accessing NFS shares.
- And now you tell us that NIS is supposed to go away as well, so we're
left with the one inferior name mapping mechanism which is *not* able
to provide supplementary groups.
So, what *is* your strategy in future to support supplementary groups?
Just ignore them entirely and leave the users in the rain?
Ashish
team that owns NFS and NIS both and there was just one request at
least 2 years back where the customer demanded this feature. Frankly
speaking - it was then I discovered this problem. Since then, you are
the second person asking for this.
People who make decisions aren't going to get convinced that it
something that's affecting a lot of people out there.
- Ashish