At 13:15 08/25/2000 -0400, you wrote:
> >>>>> "AL" == Allen Landsidel <[EMAIL PROTECTED]> writes:
>
>AL> server, but my gut instinct tells me it's the server. I would really
>AL> uneducatedly guess that the server is not switching it's effective
>user id
>AL> to that of the user issuing the request before the request is
>AL> processed. If you could, can you see if you're allowed to modify files
>AL> that you have read-only access to that are owned by another
>user/group? I
>AL> suspect you'll be able to write to any file that you can read from.
>
>Nope. If the file is owned by someone else, then all permissions
>checks work as expected.
You know, I didn't quite get it before.. but kci is the server
correct? All the other clients you listed are connection to that
server? I really should know more about NFS before trying to figure this
out, so pardon all the nfs-newbie questions...
In my guess, the server would behave this way if the client was authing
with higher user rights than your whoami is showing.. I'm assuming the
authentication happens when the remote directory is first mounted, correct
me if I'm wrong. If that's the case, then it's possible that you set up
the nfs mount as root on the two clients that don't appear to be respecting
the rights.. but here is the bottom line.
The rights on the files are filesystem rights, set on the server, without
any regard to NFS. The only users allowed to write to those files are
users/groups with +w access, root, or of course anyone if it's world
writable. The nfs server must run as a user, and the server itself is
restricted by the rights assigned to the user that it runs as. Regardless
of what the client tells it to do, it can't do it if the uid that it's
running as doesn't have the permission. This means that the server must be
running with at least and euid of root in order to carry out the request
when it overwrites the file.. two possibilities come to mind regarding this.
1. The server is running as root, and the client is authing as root when it
connects, thus giving the connection root privileges.
2. The server runs as the euid of the uid/passwd it is provided with when
the connection is established, and again the client is providing valid root
authentication when it connects.
I don't believe that NFS runs like an inetd daemon does it, instantiated on
a per/client basis? If not, then it must always be running with at least
an euid of root so that it can access all the files regardless of who the
calling user is.
It's also possible that on the clients that fail, the NFS client is suid root?
Again.. I don't know diddly about how NFS auth occurs or when.. but I
imagine it asks for a uid/passwd when you run it to mount the remote directory?
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-stable" in the body of the message
