On Mon, Apr 08, 2013 at 01:36:46PM +0300, Boaz Harrosh wrote: > From: Jim Lieb <jlieb@xxxxxxxxxxx> > > In current NFS Server (Ganesha) lots of operation becomes 6 syscalls > (Or is it 7?) > > - setfsuid(), setfsgid(), thread_setgroups() > - The OP > - Revert setfsuid(), setfsgid() to root > > This is because if we do all these file operations as root then > FS will not account for the quota a user have on create files, > data space, and so on. To make sure I understand, you're saying that: - the behavior you get out of those 6 syscalls is correct, - you just want to be able to do exactly the same thing, but with 1 syscall. (For performance?) Or is there some other issue? > (Note that permission checking is done by Ganesha core, because > We may cache open fd(s) and such not, another topic) Is there anything we could do to make it possible for you to depend on the kernel's permissions checking instead? --b. > > We could maybe with hard work save the last two calls for reverting > to root, but this will force us to audit lots of code that we are > not prepared to do right now. And will not save us much. > > [thread_setgroups()] > thread_setgroups() is what we use at Ganesha and what Samaba guys use > for a per-thread setgroups() call. In the Linux Kernel the setgroups is > actually always per thread. It is only the POSIX (crap) pthread layer > at glibc that intercepts the setgroups() call (and others), Iterates on > all threads that belong to a process, and calls the native Kernel setgroups > on them. So thread_setgroups() is just the raw syscall bypassing glibc's > processing. We will eventually push this API to glibc. > BTW: this is done exactly the same on FreeBSD, with same exact glibc intervention. > > [Proposed] > What Jim proposed is a syscall that receives a struct that has > the regular syscalls parameters plus the creds structure with fsuid/fsgid and > groups array. Kernel will set these in, call the original syscall, and revert. > This will be done on only an interested subset of the syscalls that are one - > are related to filesystems (setfsXid) and two - are of interest to us Servers. > > Jim care to scribble a structure definition? > > Thanks > Boaz > -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
