On Wed, Aug 24, 2011 at 4:44 PM, Marc Bevand <no-re...@opensolaris.org> wrote: > I run Solaris 11 Express, successfully joined an AD domain with "smbadm join" > and with a proper Kerberos config like [1]. Can anybody tell me why files > created by these users locally (on Solaris itself, not through CIFS!) end up > with the ownership of 'nobody'? > > # id > uid=0(root) gid=0(root) > # su - myu...@example.com
Given the name-based mapping rules that you give below, do you have a Unix user account called "myuser"? It's possible that nss_ad is returning an ephemeral ID here even though you have an actual name-based mapping to a Unix account. That'd be a bug, though I don't quite see how that would happen. > su: No directory! Using home=/ > $ id > uid=2147491842(myu...@example.com) gid=2147483650(Domain us...@example.com) This would indicate that no, you don't have a Unix "myuser" account. > $ touch /tmp/test > $ ls -l /tmp/test > -rw-r--r-- 1 nobody nobody 0 Aug 24 14:28 /tmp/test Right, tmpfs should not be able to handle ephemeral IDs, IIRC. > It doesn't even involve CIFS and the typical id mapping complexity... Is the > system treating the ephemeral IDs of domain users as a special case and > converting them to 'nobody'? My idmap policy is pretty standard: it is just > used to map a few domain users who have local unix accounts by the same name: The only components of the system involved here are: tmpfs, idmapd, the name services (specifically nss_ad, assuming you don't have any myu...@example.com in /etc/passwd!), and everything else that "su - someuser" would imply (e.g., a user shell). CIFS is not involved. The mapping to nobody would be made by tmpfs. We're probably missing some details though. > # idmap list > add wingroup:*@example.com unixgroup:* > add winuser:*@example.com unixuser:* > > The most puzzling thing is that this Solaris server is also serving a share > using native CIFS support (zfs set sharesmb=on xxx), and ownership of files > created by remote users through CIFS is perfectly correct. I only encounter > this problem when creating files locally (I was hoping to give my users SSH > access to allow manipulating the files locally...) As Jordan says, running Unix user processes as Windows user IDs puts you in uncharted territory -- I certainly wanted to get to where that would be supported, but when I was at Sun (then Oracle) we never got around to it, and so, though it is possible to run processes with ephemeral IDs as e/r/suid and e/r/sgid, this is not supported. There's a lot of system components that would require modification to make this work right, such as: tmpfs, utmpx/wtmpx, lastlog, nss_ad (which doesn't have, for example, _getgroupsbymember() support, IIRC), and so on. Local access to files with SIDs in their "security descriptors" is supported, but only from processes with non-ephemeral IDs for e/r/suid and e/r/sgid, and only when the files are on ZFS. Note that when I speak of "supported" I really mean that something was or was not supported when I was at Sun/Oracle. I can't speak to what is or isn't supported now, but given what Jordan has said I think it's pretty clear that either what you want is not supported or there is a bug in nss_ad(5). Nico -- _______________________________________________ cifs-discuss mailing list cifs-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/cifs-discuss
