Re: [RFC] getgroups2 system call

[christos%astron.com@localhost (Christos Zoulas)]

In article <20111213141930.GE15456%homeworld.netbsd.org@localhost>,
Emmanuel Dreyfus  <manu%netbsd.org@localhost> wrote:
>Hello
>
>FUSE has no way to send the calling process secondary groups to the
>filesystem. A filesystem that wants this operation currently has to 
>open a /proc file, read and parse the string represnetation of the 
>groups, and close the file.
>
>This is not very good performance-wise, as the filesystem needs to
>open/read/close in /proc for each file operation that require access
>control. Moreover, this can lead to deadlocks because of root vnode
>locking. 
>
>A first approach for improving this would be to fetch the secondary 
>groups using sysctl. Manuel Bouyer noted that this interface was never 
>meant to be fast, and therefore it would not address the performance issue.
>
>In a second attempt, I submitted a patch for libfuse, which would extend
>the FUSE protocol so that secondary groups could be optionnly appended
>to FUSE headers, should the filsystem request it. That did not meet 
>consensus, because on one hand, having a fixed-length header is desirable
>for optimizing performances. On the other hand, having a fixed-length
>header with an array of NGROUPS_MAX slots for secondary groups is just
>impossible on Linux, where NGROUPS_MAX is 65536.
>
>A third way was suggested on the fuse-devel mailing list: adding a
>system call to retreive a process' secondary groups. The prototype
>would be moddled on getgroups(2):
>
>       int getgroups2(int gidsetlen, gid_t *gidset, pid_t pid);
>
>Il this is preferred, it could also be named getgroupspid(2)

Don't you need a getuid2(pid_t pid)? And where does this stop? Are
you going to need other information too? The approach of adding extra
syscalls to support FUSE will make the protocol more difficult to port
across different operating systems and the new syscalls will need to be
vetted against security and usefulness. I.e. is getgroups2 limited
to the superuser? This is for VOP_ACCESS() in userland, right?

Why don't you add separate fuse messages to send and retrieve this
information? Then the kernel can notify if these have changed...

christos