Silent is definately not good. Oh well.
> Question: what semantics would be broken if CLONE_CRED was implied by
> CLONE_THREAD? Regardless of code that needs this, it would be nice to
> just save the memory when using threads. Hell, as far as I am
> concerned as long as the tasks still share a VM they could share
> credentials - but I am sure that breaks something.
Changing semantics like that is dangerous. We have no way of knowing if
any applications rely on the existing behaviour, and furthermore if
changing it will silently introduce security holes.
> Next, now that all this data no longer belongs solely to current... you
> need to be explicit about locking rules. There is a capability_lock
> spinlock but the long semantics are not 100% respected. I tried to firm
> them up in my capability.c cleanup one or two kernels ago... it should
> be good enough and not be highly contended.
Noted. Perhaps the current usage counts of the various limits should
be atomic types, or maybe the spinlock is enough. If Linus is actually
interested in the patch, this could be easily fixed up. Also, a few
parts of the kernel were suspiciously different in their use of euid/suid
instead of the plain old uid. It would be nice if someone could double
check that these places are correct.
> I guess the only downside would be the extra overhead in our
> preciously-fast do_fork... another slab allocation etc. but that is
> countered if enough stuff starts using CLONE_CRED.
I would hope that the per-cpu slab caches are fast enough.
> Oh, and what is with the #if 0 over the set and getaffinity syscalls???
> That needs to go!
Whoops, that was a dirty workaround for the breakage of 2.5.23.
-ben
-- "You will be reincarnated as a toad; and you will be much happier." - 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/