adding a system call

I know. However the Kernel Hacker's Guide writes about sys.h. After a bit of exploring, I found that sys.h has been replaced by something else in later kernels, which leaves me wondering where in the kernel I should insert my code, and where the dispatcher is located for the other system calls, in case my system call would need them.

My system call idea is to allow a superuser process to request a mmap on behalf of an user process. To see how this would be useful, let us consider svgalib.

Until now, there were two ways to allow an application access to the video array. The first was by making it setuid root, but this compromises system security by allowing it too many permissions. The second was by having a helper module which allows user applications access to the video card. However this allows any remote user to set the screen in flames.

With my new system call, a superuser process can set the graphics mode in a safe manner and then ask for an mmap of the video array into the application data segment.

Mihai
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

[...]

Ummm, couldn't the the root process open the video device, then pass the file descriptor (via AF_UNIX socket) to the user process? The user process would then call mmap() on the open file descriptor.

I'm not *completely* sure this would work, but it would avoid creating a new system call if so.

-Doug
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/

This can all be done with a device file and a corresponding module to handle the mmap and any ioctl()'s you may want to support. No need to add another system call.

BAPper

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [email protected]
Please read the FAQ at http://www.tux.org/lkml/