On Sun, Jun 04, 2006 at 01:41:54PM +0200, Nicolai Johannes wrote: > After having thought more about your suggestions, some further > questions have occured, I like to discuss: > > 1. You stated "Similarly for named pipes. I haven't thought about > SysV/POSIX IPC (shared memory, message queues, semaphores)." > > What do you mean with "similar", there is a system call mkfifo, one > can deny if PRIV_IPC_ACCEPT is not set, but how to react if a process > opens and writes/reads to a named pipe (should I modify open and read, > too)? Apropos open/read: Communication over files (open/read or mmap) > or with SIGNALS (directly via kill or indirectly via fcntl) may also > be considered as IPC. So PRIV_IPC_* would affect a lot of things.
Well, certainly the ability to create named pipes, Unix domain sockets, or fattach(3C) doors, etc..., should, perhaps be controlled by some basic privilege. But opening a named pipe for reading is, to me, akin to listen()/accept()ing on a socket, while opening a named pipe for writing is akin to connect()ing. > My suggestion is that I start with the PRIV_NET_* capabilities because > for these, I do not have to modify lots of system calls. Well, certainly you can start small and work your way up. Nico -- _______________________________________________ networking-discuss mailing list [email protected]
