> And say the app closes all file descriptors, opens a network socket and
> dup's it (blindly). Sure, the app is buggy, but that's another issue.
Which means that even with capabilites, you must still think about which
programs you want to give privileges.
> Now, the user has an easy way to (possibly) write things to the later file
> descriptors, by doing anything which will cause stderr output.
Yes, but this is almost the same as doing this:
char buffer[1024];
sprintf(&buffer, "%s %s %s %s", argv[1], argv[2], argv[3], argv[4]);
It is just plain wrong, and that program should not be given permissions.
And if a user insists on running it, the user should not be given
permissions as well. :-)
> Is this possible? Or does attempting to do something you don't have the
> capability for yield an immediate signal/death (a normally fatal SIGCAP,
> or whatever you felt like calling it)? Even if that happens, then you
> may have a different problem - a way to kill processes in critical sections
> where you might not presently be able to send them signals.
SIGCAP should be catchable IMHO. A program should be able to articulate
why it doesn't work (I've spent the WE debugging lpd, it has useful
debugging messages as "Job transfer failed" even with -D10.)
Simon
PGP public key available from ftp://phobos.fs.tum.de/pub/pgp/geier.asc
Fingerprint: 10 62 F6 F5 C0 5D 9E D8 47 05 1B 8A 22 E5 4E C1
GEEK code block available from ftp://phobos.fs.tum.de/pub/gcb/geier.asc
Hi! I'm a .signature virus! Copy me into your ~/.signature to help me spread!
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/