# NFS permissions partially working! [solved]

## orange_juice

Hallo,

I am running nfs server on x.x.x.1 and nfs client on x.x.x.2 gentoo boxes.

x.x.x.1 (the server) is using hardened sources with grsecurity enabled.

x.x.x.2 (The client) is a desktop.

The problem I face is the following:

In the nfs exported directory I have the lost+found folder with the following permissions:

```
drwx------  2 root   root   2048 2008-03-12 13:34 lost+found
```

Although nfs server will prevent the user from seeing the contents of the lost+found directory, it will allow him to delete it!!!

From my client (who is interracting with the server as user nobody:nobody) I execute the following commands that make the above statement obvious:

```
command_line@client$  cd /mnt/nfs  #the directory I have mounted nfs

command_line@client$  touch test_file

command_line@client$  ls -la

total 10

drwxrwxrwx  3 nobody nobody 2048 2008-03-12 15:45 .

drwxr-xr-x 12 flyer  sun    4096 2008-03-12 00:51 ..

drwx------  2 root   root   2048 2008-03-12 15:41 lost+found

-rw-r--r--  1 nobody nobody    0 2008-03-12 15:45 test_file

command_line@client$  ls lost+found

ls: cannot open directory lost+found: Permission denied

command_line@client$  rm -r lost+found

rm: descend into write-protected directory `lost+found'? y

command_line@client$  ls -la

total 8

drwxrwxrwx  2 nobody nobody 2048 2008-03-12 15:45 .

drwxr-xr-x 12 flyer  sun    4096 2008-03-12 00:51 ..

-rw-r--r--  1 nobody nobody    0 2008-03-12 15:45 test_file
```

How did I manage to achieve that and how can I prevent it?

What follows is the configuration of the nfs related files:

Server:

```
cat /etc/exports

/dir_to_export x.x.x.2(sync,rw,subtree_check,root_squash)
```

```
ls -la /dir_to_export

drwxrwxrwx  3 nobody nobody 2048 2008-03-12 13:35 .

drwxr-xr-x 22 root   root   1024 2008-03-12 12:00 ..

drwx------  2 root   root   2048 2008-03-12 13:34 lost+found

```

Client

```
mount

x.x.x.1:/dir_to_export on /mnt/nfs type nfs (rw,rsize=8192,wsize=8192,tcp,nfsvers=3,addr=x.x.x.1)
```

I would appreciate some help.

Kind regards,

orange_juiceLast edited by orange_juice on Thu Mar 13, 2008 3:11 pm; edited 1 time in total

----------

## eccerr0r

If the user has permission to write the directory, that user can delete anything in that directory.

The usual unix solution to this is to turn on the sticky bit +t to the directory, so that your directory permission bits will look like drwxrwxrwt (1777).

----------

## orange_juice

Thank you for your answer. Indeed, I did not have a clue what is the sticky bit and why we always use it for the tmp directory.

This change improved the situation but did not solve it.

Now, regular users do not have any rights on the lost+found folder.

However, user root on the client machine, can still delete it.

I tried to export the directory with the 'all_sqash' attribute turned on, but still no luck. 

User root, on the client machine, can still delete the 

```
drwx------  2 root   root   2048 2008-03-12 13:34 lost+found
```

 or even the 

```
drwx-----T  2 root  root  2048 2008-03-13 12:47 lost+found
```

folder of the exported directory 

```
drwxrwxrwt   6 guest guest  2048 2008-03-13 12:25 dir_to_export
```

This is my "improved but still not working as expected" /etc/exports file:

```
/dir_to_export x.x.x.2(sync,rw,subtree_check,all_squash,anonuid=302,anongid=741)
```

Kind regards,

orange_juice

----------

## eccerr0r

Normally public NFS shares are exported with root_squash, so all users that identifies themselves at root will get mapped to guest.  The NFS share should be owned by root with the sticky bit, and stuff not intended to be modified are owned by root (and due to root squash, are impossible to owner match) and chmodded such that they aren't readable.

----------

## orange_juice

Thank you!

I chowned the shared folder to root:root and chmoded the directory to 300 and everything works fine!

Kind regards,

orange_juice

----------

## slackline

 *orange_juice wrote:*   

> Thank you!
> 
> I chowned the shared folder to root:root and chmoded the directory to 300 and everything works fine!
> 
> 

 

I'm having similar headaches, and was wondering if you did this on the server or client?

Cheers

slack

----------

## orange_juice

You are right! I really had a difficulty to find out even myself!

Therefore:

The shared directory at the server is root:root (1777):

```
drwxrwxrwt  5 root     root  2048 2008-04-07 14:48 .
```

The folder inside the shared directory at the server that I do not wish to be deleted by anybody is root:root (300)

```
d-wx------  2 root     root  2048 2008-03-13 12:47 .
```

The /etc/exports file has the following entry.

```
172.16.0.2(sync,rw,subtree_check,root_squash)
```

It works fine this way.

Kind regards,

orange_juiceLast edited by orange_juice on Fri Apr 11, 2008 10:42 am; edited 1 time in total

----------

## slackline

Cool, cheers for that orange, will have a play when I get home.

slack

----------

## slackline

Finally got round to doing these small changes and setting the mod to 1777 on the server for the exported directories sorted it out fine.

Cheers for the tips,

slack

----------

