Messages in this thread | | | Subject | Re: [PATCH] capabilities not inherited | From | Alexander Nyberg <> | Date | Wed, 08 Jun 2005 23:46:57 +0200 |
| |
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/
| |