Date: Thu, 23 Mar 2006 08:57:06 -0800 (PST) From: Matthew Dillon <dillon@apollo.backplane.com> To: Peter Jeremy <peterjeremy@optushome.com.au> Cc: stable@freebsd.org Subject: Re: flushing "anonymous" buffers over NFS is rejected by server (more weird bugs with mmap-ing via NFS) Message-ID: <200603231657.k2NGv6hQ019607@apollo.backplane.com> References: <200603211607.30372.mi%2Bmx@aldan.algebra.com> <200603221427.45219.mi%2Bmx@aldan.algebra.com> <200603222020.k2MKKKIF013999@apollo.backplane.com> <200603221659.04157.mi%2Bmx@aldan.algebra.com> <200603222333.k2MNXnP8015012@apollo.backplane.com> <20060323070056.GC679@turion.vk2pj.dyndns.org>
next in thread | previous in thread | raw e-mail | index | archive | help
:This doesn't work with modes like 446 (which allow writing by everyone
:not in a particular group).
It should work just fine. The client validated the creds as of the
original operation (such as the mmap() or the original write()).
Regardless of what happens after that, if the creds were valid when
the original operation occured, then the server should allow the write.
If the client supplies root creds for a later operation and the server
translated that to mean 'write it if its possible to write without root
creds' for exports whos roots were not mapped to root, it would actually
conform better to the reality of the state of the file at the time the
client originally performed the operation verses if the client provided
the user creds of the original write.
If the file were chmoded or chowned inbetween the original write
and the actual I/O operation then it is arguable that the delayed
write I/O should succeed rather then fail.
:Doesn't that amount to significantly reducing the security of NFS?
:ISTR the original reason for "nobody" was that it was trivial to fake
:root so the server would map it to an account with (effectively) no
:privileges. This change would give root on a client (file) privileges
:equal to the union of every non-root user on the server. In
:particular, it appears that the server can't tell if a file was opened
:for read or write so a client could open a file for reading (getting a
:valid FH) and then write to it (even though it couldn't have opened the
:file for writing).
:
:--
:Peter Jeremy
No, it has no effect on the security of NFS. With the exception of
'root' creds, the server trusts the client's creds, so there isn't
going to be any real difference between the client supplying user creds
verses the server translating root creds into some non-root user's creds.
NFS has never been secure. The only reasonably secure method of
exporting a NFS filesystem is to export an entire filesystem read-only.
For any read-write export, NFS is only secure insofar as you assume
that the client can then modify any file in the exported filesystem.
The 'maproot' option is a bandaid at best, and not a very good one.
For example, exporting subdirectories of a filesystem is not secure
(and never was). It is fairly trivial for a client to supply file
handles that are outside of the subdirectory tree that was exported.
-Matt
Matthew Dillon
<dillon@backplane.com>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200603231657.k2NGv6hQ019607>