: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
середа 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
середа 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
: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
: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
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
