Re: flushing anonymous buffers over NFS is rejected by server (more weird bugs with mmap-ing via NFS)
: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 [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: flushing anonymous buffers over NFS is rejected by server (more weird bugs with mmap-ing via NFS)
середа 22 березень 2006 15:20, Matthew Dillon Ви написали: The only real solution is to make the NFS client aware of the restricted user id exported by the server by requiring that the same uid be specified in the mount command the client uses to mount the NFS partition. The NFS client would then use that user id for all write I/O operations. What about different users accessing the same share from the same client? -mi ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
flushing anonymous buffers over NFS is rejected by server (more weird bugs with mmap-ing via NFS)
середа 22 березень 2006 14:03, Matthew Dillon Ви написали: I consider it a bug. I think the only way to reliably fix the problem is to give the client the ability to specify the uid to issue RPCs with in the NFS mount command, to match what the export does. So, the problem is, the dirtied buffers _sometimes_ lose their owner and thus become root-owned. When the NFS client tries to flush them out, the NFS server (by default suspecting remote roots of being evil) rejects the flushing, which brings the client to its weak knees. 1. Do the yet unflushed buffers really have to be anonymous? 2. Can't the client's knees be strengthened in this regard? Thanks! -mi ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: flushing anonymous buffers over NFS is rejected by server (more weird bugs with mmap-ing via NFS)
:So, the problem is, the dirtied buffers _sometimes_ lose their owner and thus :become root-owned. When the NFS client tries to flush them out, the NFS :server (by default suspecting remote roots of being evil) rejects the :flushing, which brings the client to its weak knees. : :1. Do the yet unflushed buffers really have to be anonymous? : :2. Can't the client's knees be strengthened in this regard? : :Thanks! : : -mi Basically correct, though its not the buffers that get lost, its that the VM pages get disconnected from the buffers when the buffers are recycled, then get reconnected (sans creds info) later on. The basic answer is that we don't want to strengthen the client with regards to buffer/VM page creds, because buffers and VM pages are cached items in the system and can potentially have many different 'owners'. The entire cred infrastructure for buffers was a terrible hack put into place many years ago, solely to support NFS. It created a huge mess in the system code and didn't even solve the problem (as you found out). I've already removed most of that junk from DragonFly and I would argue that there isn't much point keeping it in FreeBSD either. The only real solution is to make the NFS client aware of the restricted user id exported by the server by requiring that the same uid be specified in the mount command the client uses to mount the NFS partition. The NFS client would then use that user id for all write I/O operations. -Matt Matthew Dillon [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: flushing anonymous buffers over NFS is rejected by server (more weird bugs with mmap-ing via NFS)
:What about different users accessing the same share from the same client? : : -mi Yah, you're right. That wouldn't work. It would have to be a server-side solution. Basically the server would have to accept root creds but instead of translating them to a fixed uid it should allow the I/O operation to run as long as some non-root user would be able to do the I/O op. -Matt Matthew Dillon [EMAIL PROTECTED] ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: flushing anonymous buffers over NFS is rejected by server (more weird bugs with mmap-ing via NFS)
On Wed, 2006-Mar-22 15:33:49 -0800, Matthew Dillon wrote: solution. Basically the server would have to accept root creds but instead of translating them to a fixed uid it should allow the I/O operation to run as long as some non-root user would be able to do the I/O op. This doesn't work with modes like 446 (which allow writing by everyone not in a particular group). 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 ___ freebsd-stable@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to [EMAIL PROTECTED]
