Magic groups in 2.6 [LWN.net]

Magic groups in 2.6

Posted May 13, 2004 9:35 UTC (Thu) by rjw (guest, #10415)
Parent article: Magic groups in 2.6

Why can't these features just be done via devices or special filesystems?

Ie the syscalls would take a file descriptor to a device or file, and if that checks out, allow access.

Eventually, the explosion of syscalls could be abated, and all these features accessed and permissioned through the filesystem, by just reading and writing from an fd. eg any big page mapping thing could just end up creating files which can then be mmaped.

Then only glibc needs to provide wrappers to these functions, and we can return to a small unix api, and a rich filesystem...the ideal behind plan9.

(Log in to post comments)

Magic groups in 2.6

Posted May 13, 2004 14:08 UTC (Thu) by elanthis (subscriber, #6227) [Link]

Because that would be very slow. Every syscall would require a path lookup which then requires multiple access checks. Even SELinux has been shown to have a rather noticable speed impact. If you're running a low-volume or high-security system, then speed doesn't matter. But for most web servers, desktops, and so on, speed is very very important.

Magic groups in 2.6

Posted May 13, 2004 15:54 UTC (Thu) by rjw (guest, #10415) [Link]

No, it wouldn't be.

On open, you get a file descriptor.
This is when all the access checks take place.
Everything that you want to do with that permission, you
do using the file descriptor. Hopefully via read, write, and mmap - normal system calls.

File descriptors are capabilities - not manky POSIX ones, but real ones ( with some added state about file position tacked on).
You can pass them around in order to give people access to stuff.
They are fast, because if you have the file descriptor, you have the permission. No extra checking required.

Magic groups in 2.6

Posted May 13, 2004 17:33 UTC (Thu) by elanthis (subscriber, #6227) [Link]

In order to open a file descriptor, you have to access the device node. This results already in a system call just to do this. You have to locate and read each component of the device path. So if you have even just a basic /dev/syscall file descriptor, that's three accesses including lookup (including querying the hard-disk if it's not in a file cache) for /, then /dev, and then finally /dev/syscall. So that's several syscalls, possible hard-drive access, and several access checks just to invoke a single other syscall.

Yuck.

Magic groups in 2.6

Posted May 13, 2004 21:10 UTC (Thu) by rjw (guest, #10415) [Link]

When you wish to *obtain* access to a new bit of functionality, you go and
open a file descriptior to whatever path - this is a ONE OFF cost. And it
is certainly cheaper than the other one off costs that almost all
processes incur - notably, mapping all their libraries.

After that, any calls to the functionality will be ONE syscall, which just
has to check that the fd number you passed is in the set of fds that your
process has open, and then follow a pointer to get to the file operations
structure. Do you have a solution that allows you to access privileged
functionality without syscalls? If so, I have a bridge I would like to
sell you. Or do you believe that permissions are rechecked every time a
file desciptor is used? They are not. That is the whole damn point of
them.

eg:
big_map_cap = open("/dev/caps/big_map");
//one off cost of a syscall

foreach(big_map_that_i_want){
address = do_me_a_big_map_syscall(big_map_cap, size);
// oh my god, it is a syscall!
}

So in fact, this is far cheaper than all these ridiculous system call
checkers than context switch to user space to a policy agent if the
decision isn't cached or has been thrown away.