Messages in this thread | | | Date | Mon, 24 May 1999 12:58:02 +0200 (CEST) | From | Simon Richter <> | Subject | Re: Capabilities done right [diff against 2.3.1] |
| |
On Fri, 21 May 1999, David Luyer wrote:
> 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/
| |