| All Forums |
Register |
Login |
Search |
Subscriptions |
My Profile |
Inbox |
| Tool Warehouse |
FAQs |
Resources |
Help |
Member List |
Address Book |
Logout |
|
|
User can't access his files on NFS share
|
Logged in as: Guest |
| Users viewing this topic: none |
|
Login  |
|
|
 User can't access his files on NFS share - Aug. 18, '05, 7:11:15 AM
|
|
|
hp
Posts: 25
Joined: Aug. 5, '04,
Status: offline
|
Please give me some understanding here, too:
My Interix daemon running under the local Administrators account has to read some files from a NFS share that is shared without root permissions. The permissions of these files are 0600. There is a user name mapping from a local Windows user to the Unix user whom the files belong to.
When the Interix daemon sets it's effective user ID to this local Windows user, it still can't access the files on the share. On every *nix, it would be able to access the files now.
What's the reason for this behaviour, and how can I work around it?
|
|
|
|
|
RE: User can't access his files on NFS share - Aug. 18, '05, 10:24:03 AM
|
|
|
Rodney
Posts: 3714
Joined: Jul. 9, '02,
From: /Tools lab
Status: offline
|
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).
< Message edited by Rodney -- Aug. 18, '05, 10:27:39 AM >
|
|
|
|
|
RE: User can't access his files on NFS share - Aug. 18, '05, 11:12:25 AM
|
|
|
hp
Posts: 25
Joined: Aug. 5, '04,
Status: offline
|
Rodney,
thank you very much for these informations!
I see that Interix can't allow passwordless network access without breaking the strict (paranoid?) security rules of Windows.
On the other hand, something like a seteuid(uid, password) to get network access but keep the ability to switch back to the Administrator would be a very nice thing here.
quote:
ORIGINAL: Rodney
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).
That's what I feared alredy. I did something similar in a different place before, and it was a ugly piece of work...
|
|
|
|
|
RE: User can't access his files on NFS share - Aug. 18, '05, 11:26:43 AM
|
|
|
Rodney
Posts: 3714
Joined: Jul. 9, '02,
From: /Tools lab
Status: offline
|
> On the other hand, something like a seteuid(uid, password) to get network access but keep the ability to switch back
> to the Administrator would be a very nice thing here.
Yes. I orginally had plans for all of the uid/gid (regular, effective and saved) for cacheing a "full" token.
This would address your need and others in this situation, and provide more speed in the switch-over.
It's unlikely to happen in the foreseeable future. So no one should hold their breath.
|
|
|
|
|
RE: User can't access his files on NFS share - Mar. 5, '06, 2:12:44 PM
|
|
|
BBR
Posts: 4
Joined: Jan. 5, '06,
Status: offline
|
quote:
ORIGINAL: Rodney
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".
Is group "+Administrators" also has persistent gid (131616), +Users - 131617 and so on ?
_____________________________
Boris B. Rudakov
|
|
|
|
|
RE: User can't access his files on NFS share - Mar. 5, '06, 4:31:25 PM
|
|
|
Rodney
Posts: 3714
Joined: Jul. 9, '02,
From: /Tools lab
Status: offline
|
> Is group "+Administrators" also has persistent gid (131616), +Users - 131617 and so on ?
I'm not sure what you are asking.
There are a number of id's that are "built-in" that are the same from system to system, and
thus cannot be for different accounts than originally intended.
|
|
|
|
 New Messages |
 No New Messages |
 Hot Topic w/ New Messages |
 Hot Topic w/o New Messages |
|
 Locked w/ New Messages |
 Locked w/o New Messages |
|
 Post New Thread
Reply to Message
Post New Poll
Submit Vote
Delete My Own Post
Delete My Own Thread
Rate Posts |
|
|
|
Printable Version
