Messages in this thread | | | Date | Sun, 19 Dec 1999 00:35:51 +1100 | From | Martijn van Oosterhout <> | Subject | [RFC] Problem with Linux capabilities support |
| |
Hi,
Earlier this week I posted about writing a program called scap which would allow you allow users to access certain capabilities. Little did I know that it would be impossible at the current time.
For a program like scap to give capabilities to normal users, it would need to have the privalegdes to add bits to the permitted set. At the moment this can only be done by marking the executable setuid root or hacking it to get CAP_SETPCAP priviledges and other rights.
The problem is that this obliterates the previous capabilities set. Once scap has started running, it no longer knows which capabilites the user already had active. At the moment I get around this by taking the capability set from the parent and working from that. But that is bad.
The second problem is that if scap is run setuid, at some stage it has to switch back to the previous uid, at which stage all the capabilites are cleared and your work is undone. I know that this is for compatability for userspace that does not know about capabilities, but it makes it also somewhat useless until the whole of userspace is ready. Surely we can do better than that?
The first thing that popped into my head was to define a CAP_ENLIGHTEND which can be set but not inherited. When set it would prevent uid changes from modifying the capabilities sets. When user space is ready, you can simply #define it to zero.
How does Irix handle this? Or does it also require all userspace programs be capabilities aware?
Comments??
Martijn
- 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/
| |