NFS problem: unix permissions aren't working??

Hi... I did a bit of browsing on this list and it looks to me like the
right newsgroup for my question.

Problem:

I have a file server that is nfs'ing out a local directory called
"/share" (ok, bad name, this is just a test case while I get the machine
working) If I go to this /share on the file server, or on any other
machine that mounts this, I can do the following:

(starting as root)
# cd /share
# su user1
$ touch user1file
$ chmod 600 user1file
$ exit
# su user2
$ rm user1file
rm: remove write-protected regular empty file `user1file'? y

The file "user1file" is now gone. *But* user2 is not supposed to have
permission to remove user1's file!!! Its not supposed to work like that!

If I do the same operation on the file server in the /tmp directory, I
will get:
rm: remove write-protected regular empty file `user1file'? y
rm: cannot remove `user1file': Operation not permitted

Which is, of course, what I want to see. So for some reason the shared
directory has permissions opened wide somehow.

Permissions for /share are set to be 777, because I want any user to be
able to create files within it. But one user should not be able to
modify another user's stuff unless permissions are set appropriately.

Setup:

I'll ignore the other machines as this problem is reproducable on the
file server (which is called 'windsor'). I am running NIS in order to
get the user/passwords from another server.

This file server is running Fedora Core 3. On installation I selected
the "NFS file server" option in the server install options. All I did
to get nfs working was:

create an /etc/exports file that contains one line:
/share *(rw,root_squash,no_all_squash,sync)

and start nfs using:
service nfs start

I've been mucking around in readme's and googling the subject, but
haven't found anything that is giving me the answer so I thought I'd
throw the question out the a newsgroup - as all my guru friends are on
vacation or moved or have thrown up their hands saying "you must be
doing something stupid".

"Help me, Obi Wan Kenobi, you're our only hope!"


Don

Don wrote:
>
> Hi... I did a bit of browsing on this list and it looks to me like the
> right newsgroup for my question.
>
> Problem:
>
> I have a file server that is nfs'ing out a local directory called
> "/share" (ok, bad name, this is just a test case while I get the machine
> working) If I go to this /share on the file server, or on any other
> machine that mounts this, I can do the following:
>
> (starting as root)
> # cd /share
> # su user1
> $ touch user1file
> $ chmod 600 user1file
> $ exit
> # su user2
> $ rm user1file
> rm: remove write-protected regular empty file `user1file'? y
The diagnostic is saying "you don't have write permissions on the file,
but you *do* have write permissions on the directory. Do you really
want to do this?" You reply y and it does as you say.
>
> The file "user1file" is now gone. *But* user2 is not supposed to have
> permission to remove user1's file!!! Its not supposed to work like that!
Yes it is.
>
> If I do the same operation on the file server in the /tmp directory, I
> will get:
> rm: remove write-protected regular empty file `user1file'? y
> rm: cannot remove `user1file': Operation not permitted
$ ls -ldg /tmp
drwxrwxrwt 14 root 2048 May 13 16:10 /tmp
Note the little "t". I'll bet it's not there on /share.

> Permissions for /share are set to be 777, because I want any user to be
> able to create files within it. But one user should not be able to
> modify another user's stuff unless permissions are set appropriately.
They can unless the "t" bit is set.
man 2 stat
I will concede that the explanation there is somewhat cryptic.
info chmod
is a tad better.

Allen,

Thanks, that fixed it. I figured I was doing something stupid, and once
again I haven't disppointed myself.

Don

Allen McIntosh wrote:
> Don wrote:
>
>>
>> Hi... I did a bit of browsing on this list and it looks to me like the
>> right newsgroup for my question.
>>
>> Problem:
>>
>> I have a file server that is nfs'ing out a local directory called
>> "/share" (ok, bad name, this is just a test case while I get the
>> machine working) If I go to this /share on the file server, or on any
>> other machine that mounts this, I can do the following:
>>
>> (starting as root)
>> # cd /share
>> # su user1
>> $ touch user1file
>> $ chmod 600 user1file
>> $ exit
>> # su user2
>> $ rm user1file
>> rm: remove write-protected regular empty file `user1file'? y
>
> The diagnostic is saying "you don't have write permissions on the file,
> but you *do* have write permissions on the directory. Do you really
> want to do this?" You reply y and it does as you say.
>
>>
>> The file "user1file" is now gone. *But* user2 is not supposed to have
>> permission to remove user1's file!!! Its not supposed to work like
>> that!
>
> Yes it is.
>
>>
>> If I do the same operation on the file server in the /tmp directory, I
>> will get:
>> rm: remove write-protected regular empty file `user1file'? y
>> rm: cannot remove `user1file': Operation not permitted
>
> $ ls -ldg /tmp
> drwxrwxrwt 14 root 2048 May 13 16:10 /tmp
> Note the little "t". I'll bet it's not there on /share.
>
>> Permissions for /share are set to be 777, because I want any user to
>> be able to create files within it. But one user should not be able to
>> modify another user's stuff unless permissions are set appropriately.
>
> They can unless the "t" bit is set.
> man 2 stat
> I will concede that the explanation there is somewhat cryptic.
> info chmod
> is a tad better.

I think you should read about sticky bits and their effects to
understand what you were doing.
During removing file, permission of directory comes in effect instead
of file's permission.