> > > - a MUCH truer implementation of capabilities
> > Not quite true. IMO, either you do it the whole way or don't do it. The
> > (user level) pain involved in both cases is quite similar, the benefits
> > are very different. Plus the kernel hair is significantly enhanced with
> > this kind of kludge.
> Ok, so you _are_ advocating _true_ capability support in the fs, ext3 most
> likely. That's _definitely_ what I want eventually, but I feel the latest
> incarnation of the stickybit solution takes quite a few steps in the right
> direction. Really, it can be done 99% in userspace, with kernel mods
> that:
Exactly. I'd rather work towards that than end up with two incompatible
ways of handling capabilities. Besides, I find your idea cute, but the
placement of capabilities means kernel hair that will have to be shaven
later, and AFAIU that is a no-no with Linus (quite my idea too, BTW). It
will also give strange interactions with "true" capabilities (as you call
them) later on.
[...]
> > That's why I think your idea is interesting, but doesn't quite cut it.
> Certainly not true caps in the fs, but I think this takes us very far (90%
> at least) and very quickly. An excellent candidate, I believe, for a
> kernel option to be marked [experimental]. The 'upgrade' path would be
> simple as well; in the presence of a suitable fs, a very simple utility
> could convert from this system to true fs caps.
An independent patch for people that want to fool around with capabilities
and get the hang of them perhaps, but not part (even as "experiment") of an
official (even experimental) kernel release. And in that case the security
implications are (almost) moot anyway.
Just MVHO.
-- Dr. Horst H. von Brand mailto:vonbrand@inf.utfsm.cl Departamento de Informatica Fono: +56 32 654431 Universidad Tecnica Federico Santa Maria +56 32 654239 Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513- 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/