Date: Wed, 22 Mar 2006 09:23:48 -0800 (PST) From: Matthew Dillon <dillon@apollo.backplane.com> To: Kostik Belousov <kostikbel@gmail.com> Cc: alc@freebsd.org, Mikhail Teterin <mi+mx@aldan.algebra.com>, stable@freebsd.org Subject: Re: more weird bugs with mmap-ing via NFS Message-ID: <200603221723.k2MHNmu0012943@apollo.backplane.com> References: <200603211607.30372.mi%2Bmx@aldan.algebra.com> <200603212045.39845.mi%2Bmx@aldan.algebra.com> <200603220153.k2M1rouk007739@apollo.backplane.com> <200603212107.48601.mi%2Bmx@aldan.algebra.com> <20060322091010.GA20929@deviant.kiev.zoral.com.ua>
index | next in thread | previous in thread | raw e-mail
My guess is that you are exporting the filesystem as a particular
user id that is not root (i.e. you do not have -maproot=root: in the
exports line on the server).
What is likely happening is that the NFS client is trying to push out
the pages using the root uid rather then the user uid. This is a highly
probable circumstance for VM pages because once they get disassociated
from the related buffer cache buffer, the cred information for the
last process to modify the related VM pages is lost. When the kernel
tries to flush the pages out it winds up using root creds.
On DragonFly, I gave up entirely on trying to associate creds with
buffers.
I consider this more of a bug on the server side then on the client
side. The server should automatically translate the root uid to the
exported uid for I/O ops. Or, baring that, we have to add an option
to the client-side mount to be able to specify a user/group id to
translate all I/O requests to.
-Matt
help
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?200603221723.k2MHNmu0012943>