NFS and groupspermissions.

classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

NFS and groupspermissions.

Han Boetes
Hi,

OpenBSD is the NFS-server OS; Linux is the client OS.

~% ls -l /home/public/han/nowplaying*
-rw-rw-r-- 1 han nfs 87 Mar 26 20:39 nfs/nowplaying
-rw-rw-r-- 1 han nfs 89 Mar 26 20:39 nfs/nowplayingice

On my Linux machine I have a restricted account which is member of
the group nfs and therefore should have permissions to write to
this file, allas it has not.

Actually at first I thought it was a Linux kernel error but after
reporting the bug and talking with the maintainer he found out it
was an OpenBSD-NFS bug.

Read here if you are interested in the full discussion.
  http://bugzilla.kernel.org/show_bug.cgi?id=6256

You can also find the result of `sudo tcpdump -s9000 -c100 -w file
-Nt udp port 2049' here:
  http://bugzilla.kernel.org/attachment.cgi?id=7619&action=view

Which contains a .gz file with the evidence that OpenBSD does
something wrong.

This also seems to be related to the owned of the directory in
which the file exists. IE, if I changed the owner of the file to
the restricted account, my own account -- also member of the nfs
group -- still could write to the file.


This is the matching line in exports:
  /home/public/han -maproot=han:nfs marsupilami


# Han

Reply | Threaded
Open this post in threaded view
|

Re: NFS and groupspermissions.

Han Boetes
I forgot to mention, this is the second of march snapshot.


# Han

Reply | Threaded
Open this post in threaded view
|

Re: NFS and groupspermissions.

Otto Moerbeek
In reply to this post by Han Boetes
On Sun, 26 Mar 2006, Han Boetes wrote:

> Hi,
>
> OpenBSD is the NFS-server OS; Linux is the client OS.
>
> ~% ls -l /home/public/han/nowplaying*
> -rw-rw-r-- 1 han nfs 87 Mar 26 20:39 nfs/nowplaying
> -rw-rw-r-- 1 han nfs 89 Mar 26 20:39 nfs/nowplayingice
>
>
> On my Linux machine I have a restricted account which is member of
> the group nfs and therefore should have permissions to write to
> this file, allas it has not.
>
> Actually at first I thought it was a Linux kernel error but after
> reporting the bug and talking with the maintainer he found out it
> was an OpenBSD-NFS bug.
>
> Read here if you are interested in the full discussion.
>   http://bugzilla.kernel.org/show_bug.cgi?id=6256
>
> You can also find the result of `sudo tcpdump -s9000 -c100 -w file
> -Nt udp port 2049' here:
>   http://bugzilla.kernel.org/attachment.cgi?id=7619&action=view
>
> Which contains a .gz file with the evidence that OpenBSD does
> something wrong.
>
> This also seems to be related to the owned of the directory in
> which the file exists. IE, if I changed the owner of the file to
> the restricted account, my own account -- also member of the nfs
> group -- still could write to the file.

Can or cannot?
 
> This is the matching line in exports:
>   /home/public/han -maproot=han:nfs marsupilami

I am almost able to reproduce:

I can edit the file (using vi or redirection form the shell)
But a setattr call fails, I cannot touch(1) the file, for example.

For some reason your test generates a setattr call, which is normally
not done for writing a file.

I'll investigate more.

$ ls -al
total 16
drwxr-xr-x   2 otto  wsrc   512 Mar 26 21:35 .
drwxr-xr-x  77 otto  otto  5632 Mar 26 21:35 ..
-rw-rw-r--   1 otto  wsrc     0 Mar 26 22:26 aap
$ id
uid=999(test) gid=999(test) groups=999(test), 9(wsrc)
$ echo foo > aap
$ cat aap
foo
$ touch aap
touch: aap: Operation not permitted
$
        -Otto

Reply | Threaded
Open this post in threaded view
|

Re: NFS and groupspermissions.

Ted Unangst-2
On 3/26/06, Otto Moerbeek <[hidden email]> wrote:

> On Sun, 26 Mar 2006, Han Boetes wrote:
>
> > Hi,
> >
> > OpenBSD is the NFS-server OS; Linux is the client OS.
> >
> > ~% ls -l /home/public/han/nowplaying*
> > -rw-rw-r-- 1 han nfs 87 Mar 26 20:39 nfs/nowplaying
> > -rw-rw-r-- 1 han nfs 89 Mar 26 20:39 nfs/nowplayingice
> >
> >
> > On my Linux machine I have a restricted account which is member of
> > the group nfs and therefore should have permissions to write to
> > this file, allas it has not.
> >
> > Actually at first I thought it was a Linux kernel error but after
> > reporting the bug and talking with the maintainer he found out it
> > was an OpenBSD-NFS bug.
> >
> > Read here if you are interested in the full discussion.
> >   http://bugzilla.kernel.org/show_bug.cgi?id=6256
> >
> > You can also find the result of `sudo tcpdump -s9000 -c100 -w file
> > -Nt udp port 2049' here:
> >   http://bugzilla.kernel.org/attachment.cgi?id=7619&action=view
> >
> > Which contains a .gz file with the evidence that OpenBSD does
> > something wrong.
> >
> > This also seems to be related to the owned of the directory in
> > which the file exists. IE, if I changed the owner of the file to
> > the restricted account, my own account -- also member of the nfs
> > group -- still could write to the file.
>
> Can or cannot?
>
> > This is the matching line in exports:
> >   /home/public/han -maproot=han:nfs marsupilami
>
> I am almost able to reproduce:
>
> I can edit the file (using vi or redirection form the shell)
> But a setattr call fails, I cannot touch(1) the file, for example.
>
> For some reason your test generates a setattr call, which is normally
> not done for writing a file.
>
> I'll investigate more.
>
> $ ls -al
> total 16
> drwxr-xr-x   2 otto  wsrc   512 Mar 26 21:35 .
> drwxr-xr-x  77 otto  otto  5632 Mar 26 21:35 ..
> -rw-rw-r--   1 otto  wsrc     0 Mar 26 22:26 aap
> $ id
> uid=999(test) gid=999(test) groups=999(test), 9(wsrc)
> $ echo foo > aap
> $ cat aap
> foo
> $ touch aap
> touch: aap: Operation not permitted
> $

this is normal.  setattr only works if you are the owner of the file.
why the client has suddenly decided that it needs to do a setattr when
it didn't yesterday is beyond me.

Reply | Threaded
Open this post in threaded view
|

Re: NFS and groupspermissions.

Han Boetes
In reply to this post by Otto Moerbeek
Otto Moerbeek wrote:
> On Sun, 26 Mar 2006, Han Boetes wrote:
> > This also seems to be related to the owned of the directory in
> > which the file exists. IE, if I changed the owner of the file to
> > the restricted account, my own account -- also member of the nfs
> > group -- still could write to the file.
>
> Can or cannot?

Can.

 

> > This is the matching line in exports:
> >   /home/public/han -maproot=han:nfs marsupilami
>
> I am almost able to reproduce:
>
> I can edit the file (using vi or redirection form the shell) But
> a setattr call fails, I cannot touch(1) the file, for example.
>
> For some reason your test generates a setattr call, which is
> normally not done for writing a file.

Yes you are right. I was unclear on that part. Since the latest
update to the linux kernel -- 2.6.16 -- the restricted account
could no longer write to the file.

Previous released did allow writing, but not to use setattr.

I'll reopen the bugreport for Linux as well.

Always remarkable the way that both NFS implementations bite each
other.  For example the SUN implementation does allow setattr.

What is the reason behind disallowing setattr?



# Han

Reply | Threaded
Open this post in threaded view
|

Re: NFS and groupspermissions.

Otto Moerbeek
On Mon, 27 Mar 2006, Han Boetes wrote:

> Otto Moerbeek wrote:
> > On Sun, 26 Mar 2006, Han Boetes wrote:
> > > This also seems to be related to the owned of the directory in
> > > which the file exists. IE, if I changed the owner of the file to
> > > the restricted account, my own account -- also member of the nfs
> > > group -- still could write to the file.
> >
> > Can or cannot?
>
> Can.
>
>  
> > > This is the matching line in exports:
> > >   /home/public/han -maproot=han:nfs marsupilami
> >
> > I am almost able to reproduce:
> >
> > I can edit the file (using vi or redirection form the shell) But
> > a setattr call fails, I cannot touch(1) the file, for example.
> >
> > For some reason your test generates a setattr call, which is
> > normally not done for writing a file.
>
> Yes you are right. I was unclear on that part. Since the latest
> update to the linux kernel -- 2.6.16 -- the restricted account
> could no longer write to the file.
>
> Previous released did allow writing, but not to use setattr.
>
> I'll reopen the bugreport for Linux as well.
>
> Always remarkable the way that both NFS implementations bite each
> other.  For example the SUN implementation does allow setattr.
>
> What is the reason behind disallowing setattr?

I'll explain a bit. setattr can be used to modify various attributes
of a file: time stamps and size for example.

The utimes(2) syscall allows setting timestamps if you're owner or
superuser and it allows setting the timestamps to the current time if
you may write the file.

In the case of NFS, the umodes(2) call issues a setattr NFS request.
The NFS setattr call does not know this "set to current time" case,
and only allows the owner to set the timestamps.

Linux has a hack in its NFS server to allows setting the timestamps
"if close enough to current time". This is a real hack, since it
requires some form of time coherence between server and client.

Anyway, as you already mentioned, the linux client behaviour is a
regression, it issues an setattr call it did not do before.

The touch(1) error I'm seeing is a consequence of my change to
touch.c: previously it used read/write code with all kinds of races to
modify the timestamp if the utimes(2) call failed. That code was
removed and the error reported by utimes(2) is now shown.

I'll have to take a look into Solaris to see how they handle things.

        -Otto

Reply | Threaded
Open this post in threaded view
|

Re: NFS and groupspermissions.

Otto Moerbeek
On Mon, 27 Mar 2006, Otto Moerbeek wrote:

> The utimes(2) syscall allows setting timestamps if you're owner or
> superuser and it allows setting the timestamps to the current time if
> you may write the file.
>
> In the case of NFS, the umodes(2) call issues a setattr NFS request.
> The NFS setattr call does not know this "set to current time" case,
> and only allows the owner to set the timestamps.

This is true for NFS v2. Version 3 does seem to have some more
facilities here. Digging deeper...

        -Otto

Reply | Threaded
Open this post in threaded view
|

Re: NFS and groupspermissions.

Rick Macklem-3
In reply to this post by Han Boetes
Does the setattr set the size? There is an additional check in this case
and the one in OpenBSD3.8 is more restrictive than is the "fashion" these
days. Most servers allow the owner to write/setattr-size, no matter what
the permission modes say. I don't know if this is causing your problem,
but I do know that Solaris10 clients won't like it, if you don't allow
the setattr-size to happen for the owner, even if the modes bits say "no".

Here is what my current server code has in it:
                if (va2.va_uid != nd->nd_cred->cr_uid ||
                    (exflag & MNT_EXSTRICTACCESS)) {
                        nd->nd_repstat = nfsrv_accchk(vp, VWRITE,
                                nd->nd_cred, exflag, p, 0);
                        if (nd->nd_repstat)
                                goto out;
                }
ie. It only checks the mode bits if not the owner OR a "-strict" export
flag has been put on the mount point. (To be honest, I only put the "-strict"
mount point flag in to keep anyone who believes this is a security hole
happy. I don't see why it should ever be used. After all, NFS using auth_sys
has no security anyhow, except for firewalling based on client IP address.)

rick