| Rodney -> RE: User can't access his files on NFS share (Aug. 18, '05, 10:24:03 AM) |
There is a difference in the security models and, most particularly, how they are implemented.
With the typical and historic Unix model the UID and GID identify the user and group that the
process is running as; there is also the same for effective UID and GID. The association with
these UID's/GID's provides all of the security context of the process. With this UID/GID combo
you have the right to do XXX -- no more, no less.
With an NT process (and I call it an NT process since this applies to all process types:
Interix, Win32, OS/2, and Native {Win32 != Native}) each running process has a set of ACL's
(Access Control List). This is very similar to the ACL's for disk files, but for the process.
There is for each process a security token that is an ACL. It identifies the SID's associated
with the process (akin to UID's/GID's and user), but this does not infer that all rights and
privileges associated with these SID's automatically. NT also separates rights and privileges
are two separate things (though most discussions either treat them the same or blur the distinction).
The ACE's (Access Control Entries) in the ACL can list a large, complex array of permissions that
are granted or denied. But there are some other identifiers in the security token. One of these
is an identifier/marker by the security system (in the kernel). This marker is usually used in a lookup
because it's a unique number (I'll skip over details for now).
Now to your question:
When a daemon is running, it runs by default as local Administrator (uid 197108).
The Interix subsystem allows 197108 the special ability to behavior more like the typical "Unix root".
Like with Unix, this ability is associated with the UID (197108). So 197108 can, by the special ability,
become another user without needing a password (as your daemon does). But this ability is powerful. So
a constraint of this ability is that the security token is valid for the local machine only. The marker,
mentioned earlier, will not validate with a lookup (finer details skipped for brevity). If during the
change from one user to another the password for the end-user is provided then a security token is
created with a marker that validates on lookup.
So why does this apply to NFS which in implementation doesn't really give a hoot? Give NFS a UID and
it normally is quite happy to give whatever you ask for. Well it has to do with the implementation of
the client driver on the Windows side. The Windows driver is doing work for (potentially) many processes
for different users. So the driver change (impersonates) the requesting process based on the requesting
processes security token (this is done via the NT kernel's LPC system). Since the marker is invalid
then the driver says "no-go" in mapping the SID to a UID for the NFS request (remember the NFS request
is stateless so this info is sent each time). So, Bob's your uncle, no off machine disk access.
A Unix NFS client would just pass the UID through.
The work-around is to change the user not using seteuid() but to user setuser() and provide a password
(xref the setuser man page). The downside is that this replaces the calling process' token. So you'd
need to fork off a child and stream the information back to the parent (likely through a pipe). |
|
|
|