Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 25 Aug 2000 13:52:36 -0400
From:      Allen Landsidel <all@biosys.net>
To:        freebsd-stable@freebsd.org
Subject:   Re: NFS client ignores "read-only" attribute on file
Message-ID:  <4.3.2.7.2.20000825133648.00b5ca80@mail.megapathdsl.net>
In-Reply-To: <14758.43416.82239.11410@onceler.kciLink.com>
References:  <4.3.2.7.2.20000825120608.00b4d4a8@mail.megapathdsl.net> <14758.38824.440415.870831@onceler.kciLink.com> <4.3.2.7.2.20000825120608.00b4d4a8@mail.megapathdsl.net>

next in thread | previous in thread | raw e-mail | index | archive | help
At 13:15 08/25/2000 -0400, you wrote:
> >>>>> "AL" == Allen Landsidel <all@biosys.net> 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 majordomo@FreeBSD.org
with "unsubscribe freebsd-stable" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4.3.2.7.2.20000825133648.00b5ca80>