I think that you're honestly better off creating some kind of pipe or socket where the commands come through, which has a list of functions that it can provide. That way you can have a list, and see if there's a match for what's sent. It'd really be quite hard to implement a SUID type of arrangement here in a way that's secure... a lot of variables.
That discussion of server-running-with-capabilities versus setuid-binary is basically the same as on normal unix anyway. You could remove the setuid functionality completely from unix if you (are able to) always arrange for an already-running program with the target capabilities. With one (only one?) exception, which is that the server cannot determine which user is at the other end of the socket (Dan Bernstein, the Qmail developer, has written a page complaining about this). And of course it could be difficult or resource wasting to have daemons running for all possible purposes.
I think in a way vserver basically just extends the normal linux/unix permission system to the next level; setuid in linux/unix already works, now it "would have" to be extended to the vserver functionality as well. (And checksums should not be needed, rather it should be that the relevant files are immutable by vservers - just like where in the normal setuid case, an insecure user should not be able to modify any file of a setuid application.)
However, I don't think such a "setxid-bit" (set-context) functionality would be important for me, and since one reason to choose vserver (over just normal user accounts on a vserver-less machine) is to protect against the risks of setuid binaries (local root holes), introducing setxid binaries would sort of defeat the purpose of vserver :-)
Christian. _______________________________________________ Vserver mailing list [EMAIL PROTECTED] http://list.linux-vserver.org/mailman/listinfo/vserver
