Re: [PATCH] capabilities not inherited

[Alexander Nyberg <alexn@telia.com>]

ons 2005-06-08 klockan 16:33 -0500 skrev Manfred Georg:
> On Wed, 8 Jun 2005, Alexander Nyberg wrote:
> > btw since the last discussion was about not changing the existing
> > interface and thus exposing security flaws, what about introducing
> > another prctrl that says maybe PRCTRL_ACROSS_EXECVE?
> 
> Wasn't the original inherited set supposed take care of that?

Yes

> > Any new user-space applications must understand the implications of
> > using it so it's safe in that aspect. Yes?
> 
> As far as I can tell, applying the patch from the earlier discussion
> and setting the inherited set has the same, "I really meant to do this"
> effect as what you propose.

But since it didn't do what it was supposed to from the beginning some
people don't want to change it because it might open up security holes
and I can understand that. So maybe we need some new flag for
applications to say "I really want to do this" and noone can say we
break old interfaces (mess upon mess...)

> > (yeah it's rather silly since there already is an unused
> > keep_capabilities flag but that would change old interfaces so ok)
> 
> Isn't the keep_capabilities flag related to setuid() ? or did I miss
> something.
> 

Yeah it's related to changing user IDs, it's me who is lost, sorry.

And I still think having apps being able to keep a chain of capabilities
would be very useful, most noticeable pam_cap so that normal users can
have capabilities like chroot, running SCHED_FIFO or SCHED_RR, mlock
etc. But let's see what Chris has to say about another flag for explicit
inheritance.

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/