Messages in this thread | | | Date | Mon, 3 Jul 2000 16:18:22 +0200 | From | Ralf Baechle <> | Subject | Re: Capabilities primer |
| |
On Sun, Jul 02, 2000 at 02:54:52AM +0200, Felix von Leitner wrote:
> Let's assume that I want to write a small wrapper that runs apache with > UID foo and GID bar in a chroot jail with the capability to bind to a > port < 80. > > Thus, I need a way to start a process with UID foo and > cap_net_bind_service, right? > > There are packages to do this, but > > - suexec always says "permission denied" > - compartment only allows capabilities on uid 0 processes. > The documentation says that "this will change with 2.4.0". > I am using 2.4.0-test2.
> Um, what now? The capability FAQ recommends that I edit the kernel > sources to give /sbin/init the cap_setcap capability. I don't want to > give all processes this capability and I don't have a special init, so > this does not fix anything.
You won't give this capability to all processes. Unless PR_SET_KEEPCAPS is set changing the uid of the process will drop all capabilities. This option is then also the only way to pass capabilities to a non-root process. You can further limit the capability inheritance by removing a capability from the inherited set.
> Do I fail to understand something here? I thought the was the very > reasons why capabilities were implemented in the first place? We had > securelevel for the other use case. > > But then, maybe I'm just too dumb and need some cut-and-paste examples > on how to use capabilities for something useful. ;-) Please go ahead > and email them to me.
Capabilities are just not production ready.
Ralf
- 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/
| |