Re: Possible permissions bug on NFSv3 kernel client

Re: Possible permissions bug on NFSv3 kernel client

[Pascal Schmidt]

On Thu, 29 Apr 2004 19:50:06 +0200, you wrote in linux.kernel:

>> ...so that the the MODIFY and EXTEND bits aren't set when writing to a
>> block or character device.
>
> Hmm... Why shouldn't the MODIFY bit at least be set if the user
> requested write access to the device?

It's somewhat of a mixed-up situation for device nodes exported via
NFSv3. Permission bits are on the server, but the actual write does
not happen via NFS (as v3 WRITE only works on regular files).

-- 
Ciao,
Pascal

Re: Possible permissions bug on NFSv3 kernel client

[Trond Myklebust]

On Thu, 2004-04-29 at 16:49, Pascal Schmidt wrote:
> On Thu, 29 Apr 2004 19:50:06 +0200, you wrote in linux.kernel:
> 
> >> ...so that the the MODIFY and EXTEND bits aren't set when writing to a
> >> block or character device.
> >
> > Hmm... Why shouldn't the MODIFY bit at least be set if the user
> > requested write access to the device?
> 
> It's somewhat of a mixed-up situation for device nodes exported via
> NFSv3. Permission bits are on the server, but the actual write does
> not happen via NFS (as v3 WRITE only works on regular files).

It's not "mixed up" at all: the permissions checking has to be done by
the server, period.
All the file security information (the mode bits, owner uid, group gid,
ACLs etc) that determine whether or not the open() should succeed are
defined on the *server* not on the client. If the former is doing some
form of mapping of those values (in particular if it is doing some form
of root/uid/gid squashing) then the only way for the client to get it
right is to make an ACCESS call.

The fact that the subsequent writes go to a device on the client is
entirely irrelevant.

Cheers,
  Trond

Re: Possible permissions bug on NFSv3 kernel client

[Pascal Schmidt]

On Thu, 29 Apr 2004 23:30:50 +0200, you wrote in linux.kernel:

> It's not "mixed up" at all: the permissions checking has to be done by
> the server, period.

Then it's at least inconsistent with local filesystem behaviour. fsck
has no problem opening device nodes for writing on my root filesystem
even though it is mounted read-only at that point.

-- 
Ciao,
Pascal

Re: Possible permissions bug on NFSv3 kernel client

[Trond Myklebust]

On Fri, 2004-04-30 at 16:17, Pascal Schmidt wrote:
> Then it's at least inconsistent with local filesystem behaviour. fsck
> has no problem opening device nodes for writing on my root filesystem
> even though it is mounted read-only at that point.

So why do you think that is inconsistent with my statement: "the
permissions checking has to be done by the server, period"?

The read-only mount option is a *local* override of the write
permissions on the server. It applies to regular files, directories, and
soft links *only*.
The read-only mount option does *not apply* to char/block devices such
as /dev/hd[a-z]*, /dev/tty*. Permission checks on open() for those
devices are done on the server *only* via the ACCESS rpc call.

This should be entirely consistent with local file behaviour.
Particularly since the code to deal with the read-only mount option in
nfs_permission() was pretty much cut-n-pasted from vfs_permission().

Cheers,
  Trond

Re: Possible permissions bug on NFSv3 kernel client

[Pascal Schmidt]

On Fri, 30 Apr 2004, Trond Myklebust wrote:

> So why do you think that is inconsistent with my statement: "the
> permissions checking has to be done by the server, period"?

I see it wasn't clear from my reply. I don't disagree at all.
Permission checking is the server's job. Clients are untrusted.

> This should be entirely consistent with local file behaviour.
> Particularly since the code to deal with the read-only mount option in
> nfs_permission() was pretty much cut-n-pasted from vfs_permission().

The original poster said it didn't work for him on an NFSv3 mount.
Looking at nfs_permission() I (of course) agree it looks innocent
enough.

-- 
Ciao,
Pascal

Re: Possible permissions bug on NFSv3 kernel client

[Colin Paton]

Hi,

> So why do you think that is inconsistent with my statement: "the
> permissions checking has to be done by the server, period"?

I agree that permission checking should be done by the server. However,
I believe that in this case the client is requesting the wrong
permissions. As writing to a char/block device does not perform a write
operation *on the server* then the client should not be asking the
server for modify/extend permission in the case of char/block devices.

> The read-only mount option does *not apply* to char/block devices such
> as /dev/hd[a-z]*, /dev/tty*. Permission checks on open() for those
> devices are done on the server *only* via the ACCESS rpc call.

Should vfs_permission() (as called from nfs_permission) be sufficient to
perform this check?

> 
> This should be entirely consistent with local file behaviour.

I don't believe that it is... it is possible to write to a block device
on a filesystem that is mounted read-only, but not to write to a block
device on an NFS filesystem that is *exported* read-only. 

I think that nfs_permission() may do sufficient checking - I believe the
problem is in nfs3_proc_access() - where the client is asking the server
for more permissions than it needs.

Colin

Re: Possible permissions bug on NFSv3 kernel client

[Trond Myklebust]

On Tue, 2004-05-04 at 05:55, Colin Paton wrote:
> As writing to a char/block device does not perform a write
> operation *on the server* then the client should not be asking the
> server for modify/extend permission in the case of char/block devices.

Sure it should: you are asking it for write permission! If you didn't
check the for modify/extend, then you be allowing world write permission
by default.

I just checked that Sun's NFS client indeed checks both "extend" and
"modify" when attempting to write to a character device.

> > The read-only mount option does *not apply* to char/block devices such
> > as /dev/hd[a-z]*, /dev/tty*. Permission checks on open() for those
> > devices are done on the server *only* via the ACCESS rpc call.
> 
> Should vfs_permission() (as called from nfs_permission) be sufficient to
> perform this check?

No! I repeat: vfs_permission() knows nothing about any uid/gid
mapping/squashing. You cannot rely exclusively on the mode bits in NFS.

> I don't believe that it is... it is possible to write to a block device
> on a filesystem that is mounted read-only, but not to write to a block
> device on an NFS filesystem that is *exported* read-only. 

That sounds like a server bug, then.

Cheers,
  Trond

Possible permissions bug on NFSv3 kernel client

[Colin Paton]

Hi,

I have found what I think might be a bug with the kernel NFS v3 client
code. It is however more likely that I am doing something wrong -
perhaps someone might verify my attempted fix!

Google suggests that other people might be having the same problem - but
I couldn't find a fix so had a go myself.

I am trying to export a filesystem as read-only from a server. On my
client machine I boot into an initial filesystem, mount the 'real' root
filesystem over NFS, then pivot_root to it. 

If I mount the root filesystem as NFSv2 (using mount -o nfsvers=2) then
everything works correctly. If I mount as NFSv3 then I run into problems
when trying to write to block/character device files.

Both the client and the server are using kernel 2.4.25, with knfsd on
the server. I case it matters, I am using busybox 1.00-pre8 mount, but
the same thing happens with mount version 2.11n on a Debian system.

Essentially, it does not appear to be possible to write to device files
which are mounted on a read-only NFSv3 filesystem. The problem only
occurs with NFS v3 - Mounting the filesystem as NFSv2 (using mount -o
nfsvers=2) is fine.

To reproduce:

- On a server machine create a character device file on a read-only NFS
exported directory (called 'tty3' in this example)
- Mount the NFS volume on a client machine.
- From the client machine, run 'cat > /mnt/tty3'

The kernel returns EACCES when trying to open the 'tty3' device.

The 'cat > /mnt/tty3' command works properly if the directory is
exported read-write.

Reading from the device file (cat < /mnt/tty3) is fine in all cases.

Doing a trace with ethereal shows that an NFS 'access' RPC is sent to
the server, with the access bitmask set to 'allow MODIFY+EXTEND'. The
server returns that these are not allowed, as the filesystem is mounted
read-only. This causes the EACCES error.

I modified the client kernel code as follows, to make the NFS client
behave differently:

In file: fs/nfs/nfs3proc.c modify nfs3_proc_access(). This calls the
access RPC on the server. I added the following to the code:

            if (S_ISBLK(inode->i_mode) || S_ISCHR(inode->i_mode))
                {
                    // Leave arg.access untouched.
 
                }

...so that the the MODIFY and EXTEND bits aren't set when writing to a
block or character device.

This fix works, yet I believe it might introduce a security problem. I
am not sure where permissions should be properly checked.

The access RPC appears specific to NFS v3. I am not sure how NFS v2 does
permissions checking.

In addition, I am not 100% sure if the problem is at the client end or
the server end - have I just masked the problem rather than actually
fixing it?

Alternatively, of course, there may be some specific reason why NFSv3 is
not recommended for root filesystems - in which case it might be better
to fall back to NFSv2.

Thanks,

Colin

Re: Possible permissions bug on NFSv3 kernel client

[Trond Myklebust]

On Thu, 2004-04-29 at 07:02, Colin Paton wrote:

> In file: fs/nfs/nfs3proc.c modify nfs3_proc_access(). This calls the
> access RPC on the server. I added the following to the code:
> 
>             if (S_ISBLK(inode->i_mode) || S_ISCHR(inode->i_mode))
>                 {
>                     // Leave arg.access untouched.
>  
>                 }
> 
> ...so that the the MODIFY and EXTEND bits aren't set when writing to a
> block or character device.

Hmm... Why shouldn't the MODIFY bit at least be set if the user
requested write access to the device?

Cheers,
  Trond