Group name madness: "CurrentSession" vs. "LogonSessionId_0_111590" vs. "NT AUTHORITY\LogonSessionId_0_111590" ...

[Roland Mainz]

Hi!

----

While implementing chown/chgrp support in the ms-nfs41-client (Windows
NFSv4.1 client filesystem driver) I encountered an issue with group
names.

I tried a simple $ chgrp CurrentSession myfile #, which returned
"Permission denied".
OK, /usr/bin/id -a shows that the current user is a member of this
group, so I added a new group called "CurrentSession" to the NFSv4.1
server side ([1]).
But that did not work either, /usr/bin/chgrp # still failed.

Enabling debug output (see https://nrubsig.kpaste.net/ed343a8) I saw
something weird: The filesystem driver gets the group as SID, but
converting this SID back into a Windows Account name (which is used as
NFSv4 group name string) returned "LogonSessionId_0_111590", NOT
"CurrentSession".

1. Why is this happening ? Who or what defines "CurrentSession" ?
2. Why does $ getent group LogonSessionId_0_111590 # not work, even if
this is a legal Windows account name ?
3. $ getent -w group CurrentSession # has "NT
AUTHORITY\LogonSessionId_0_111590" as a field value, but neither
"LogonSessionId_0_111590" nor "NT AUTHORITY\LogonSessionId_0_111590"
return matches when passed to $ getent -w group ... # - is this
intended ?

[1]=Unlike NFSv2/NFSv3 the NFSv4 protocol uses user and group names as
strings, and no longer uses integer values. So usernames and group
names must match, not no longer the |uid_t|/|gid_t| values. That can
be used to avoid |uid_t|/|gid_t| collisions, and allows "identify
mapping", e.g. via a idmapd daemon.

----

Bye,
Roland
-- 
  __ .  . __
 (o.\ \/ /.o) roland.mainz@nrubsig.org
  \__\/\/__/  MPEG specialist, C&&JAVA&&Sun&&Unix programmer
  /O /==\ O\  TEL +49 641 3992797
 (;O/ \/ \O;)