NFS misbehaviour with Linux server

[Matthias Drochner]

Hi -
when I did a system rebuild after our (my company's) NFS
server was switched from a DEC OSF/1 cluster to a Linux box
I had to find out that all SUID bits of my (diskless)
development system disappeared.

I tracked it down to the following:
-NetBSD's "install" program does a fchmod() on the open file
descriptor of the file being installed, and a close()
afterwards. This makes, due to caching etc that an NFS
WRITE is done to the file after the SETATTR.
-Linux (Debian, 2.6 kernel) appearently deletes the SUID bits
if a file is written to. The NFS WRITE reply contains the
new non-suid attributes.

Is this legal, or well-known, behaviour? I couldn't find
anything in the NFSv3 spec telling that the server is allowed
to change attributes unrequested, or that the client should
check every attribute coming back whether it has changed
unexpectedly.

Or is this a Linux security feature which I can hopefully
switch off?

(I can send a tcpdump capture file if anyone is interested.)

best regards
Matthias


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Jason Thorpe]

Post by Matthias Drochner
Is this legal, or well-known, behaviour? I couldn't find
anything in the NFSv3 spec telling that the server is allowed
to change attributes unrequested, or that the client should
check every attribute coming back whether it has changed
unexpectedly.

This sounds like a bug in the Linux NFS server to me.

-- thorpej


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Matthias Drochner]

Post by Jason Thorpe
This sounds like a bug in the Linux NFS server to me.

To me too... But this is caused by an obviously intentional and
even commented piece of code (see fs/nfsd/vfs.c:nfsd_vfs_write()).
I don't have any hope that this will be fixed in Linux, and while
I could fix the kernel on our server, this would get lost when
someone else (or myself after having forgot about the issue) installs
a kernel update.
A workaround on the NetBSD side is easy: just flush the file before
the SETATTR call, see the appended patch. (Actually, it would probably
not hurt to flush regular files before every SETATTR to simplify the code.)

Just to share what I've found out wrt write() vs. suid bits:
SUSv3 says that the system _may_ delete suid flags on writes. OSF/1
deletes them always. NetBSD keeps them if the write() is done by
root and deletes otherwise. (This is hardwired in the ufs code,
w/o consulting the secmodel stuff btw.) In any case this should be a
local policy thing and not forced to NFS clients, that's why I think
that Linux is wrong.

best regards
Matthias

[YAMAMOTO Takashi]

Post by Matthias Drochner

Post by Jason Thorpe
This sounds like a bug in the Linux NFS server to me.

To me too... But this is caused by an obviously intentional and
even commented piece of code (see fs/nfsd/vfs.c:nfsd_vfs_write()).
I don't have any hope that this will be fixed in Linux, and while
I could fix the kernel on our server, this would get lost when
someone else (or myself after having forgot about the issue) installs
a kernel update.

i think the behaviour is a common practice.
it isn't appropriate to blame linux nfsd for it.

Post by Matthias Drochner
A workaround on the NetBSD side is easy: just flush the file before
the SETATTR call, see the appended patch. (Actually, it would probably
not hurt to flush regular files before every SETATTR to simplify the code.)

it seems fine. please commit.

YAMAMOTO Takashi

--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Jed Davis]

Post by YAMAMOTO Takashi

Post by Matthias Drochner

Post by Jason Thorpe
This sounds like a bug in the Linux NFS server to me.

To me too... But this is caused by an obviously intentional and
even commented piece of code (see fs/nfsd/vfs.c:nfsd_vfs_write()).
I don't have any hope that this will be fixed in Linux, and while
I could fix the kernel on our server, this would get lost when
someone else (or myself after having forgot about the issue) installs
a kernel update.

i think the behaviour is a common practice.
it isn't appropriate to blame linux nfsd for it.

Especially because NetBSD's nfsd does the same thing; when I ran into
this a number of months ago (and then promptly forgot to open a PR), I
was able to reproduce it between two NetBSD 2.0.x systems.
--
(let ((C call-with-current-continuation)) (apply (lambda (x y) (x y)) (map
((lambda (r) ((C C) (lambda (s) (r (lambda l (apply (s s) l)))))) (lambda
(f) (lambda (l) (if (null? l) C (lambda (k) (display (car l)) ((f (cdr l))
(C k))))))) '((#\J #\d #\D #\v #\s) (#\e #\space #\a #\i #\newline)))))


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de

[Matthias Drochner]

Post by Jed Davis
Especially because NetBSD's nfsd does the same thing

Ah yes, since the SUID removal is done within filesystem
specific code, the nfs server will get this too. And it can't
be changed easily.
(It would probably make sense to do the suid stuff at a higher
level, so that a common policy is enforced, and local and NFS
can be dealy with differently.)

Post by Jed Davis
I was able to reproduce it between two NetBSD 2.0.x systems

Do you want pullups?

best regards
Matthias


--
Posted automagically by a mail2news gateway at muc.de e.V.
Please direct questions, flames, donations, etc. to news-***@muc.de