> > > It was meant to work with capabilities in the filesystem like setuid bits. > > > So the patches that have floated around from myself, Andy Lutomirski > > > and Alex Nyberg are attempts to make something half-way sane out of the > > > mess. The trouble is then convincing yourself that it's not some way to > > > leak capabilities (esp. since some programs use the interface already, > > > like bind9). > > > > Anyone who uses the current interfaces should not play with the > > inheritable flag, the text I looked at said it was specifically for > > execve. Thus if the application doesn't modify the inheritable mask > > things will look like it has always done. And it really should not mess > > with inheritable mask if it doesn't intend to, that would be a security > > bug. > > We really should be safe doing this. > > That's one of the points. Latent bugs getting triggered is what makes > the change deserving of being conservative.
bind9 actually sets inheritable, but I don't see it doing any exec in the whole package, so it should be safe. I'll look for other large common packages using capabilities. I don't think this necessarily is 2.7 material, but otoh if it has waited this long there doesn't appear to be that kind of rush to get it in. > > > All I can say is work is underway. There's 3 different patches that > > > will get you to your goal. I understand that it's a real pain right now. > > > One of the authors of the withdrawn draft has told me that the notion of > > > capabilities w/out filesystem support was considered effectively useless. > > > So, we're in uncharted territory. BTW, thanks for reminding me of > > > scripts, I had been testing just C programs. > > > > I wouldn't call it useless, retaining capabilities across execve + > > pam_cap is a very useful thing, on my machine I can give myself a few > > capabilities that have always annoyed me (iirc the database that wanted > > mlock as regular user would have been solved aswell). > > Yes, that's useful, but having 3 sets and complicated rules for > combining task and file based sets is not really necessary for that. However I never saw any real clean solution for the problem and I would call this better and more general for this kind of problems. > > Regarding fs attributes: > > http://www.ussg.iu.edu/hypermail/linux/kernel/0211.0/0171.html > > > > I can see useful scenarios of having the possiblity of capabilities per > > inode (it appears the xattr way wins somewhat in the previous > > discussion). > > It's how it should be done. > > > Chris, have you seen any capabilities+xattr patches around? > > http://www.kernel.org/pub/linux/libs/security/linux-privs/kernel-2.4-fcap/ Thanks, I'll have a look at this. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/