On 11-02-18 20:55, John A. Sullivan III <jsullivan@opensourcedevel.com> wrote:
On Fri, 2011-02-18 at 20:14 +0100, Alexander Wuerstlein wrote: We use a local x2gousers group on the VM. We create it and add the user to it (in fact, the VM hostname is the same as the globally unique user uid) as part of the VM creation.
So I assume e.g. on host 'mike' the user named 'mike' is a local (only on that host) member of group 'x2gousers'? If thats the case, just install all x2gowrappers executable to the 'x2gousers' group only and you are done. So its just a minimal change to your standard VM image that would be needed. But for non-repudiation you will also need to prevent any other user than 'mike' from logging in to the host 'mike' by ssh, so if your setup works as intended, the permisions on the wrapper will be your second line of defense, not your first.
Yes, it does on small scales. And our approach wouldn't make the 'x2gousers' group go away if you still want to use it: You can simply make the x2gowrapper executable only for that group and not for others. Then you have exactly the same functionality as with 'sudo', but without the hassle of setting up the sudo configuration (wich does never seem to work automatically on installation). That would also be the suggested migration path i guess. Additionally you can of course use database black/whitelists, or you can set x2gowrapper o+rx and only use database black/whitelists. In that sense our approach would also be far more flexible than the current sudo approach. <snip>
I suppose this is true and appreciate the flexibility. Just as we automate the creation of the group, we could simply change the group ownership of x2gowrapper to the user's personal group and remove world access. Is that a correct understanding of how we could use what you are proposing? I do hope those ownership and permissions changes wold be preserved across an update. Otherwise, I could see a security nightmare.
You could also change the group to the user's private group, but I guess that would be much more complicated than the approach described above. And I agree that perhaps the postinstall script should take care not to mess up the permissions of the wrapper if they have been changed (Or perhaps a debconf question would be useful?).
Again, our use shouldn't drive this decision but I wonder how many others have variations on our theme for issues like billing, security, and non-repudiation. Thanks again for opening the discussion; I hope it is proving helpful rather than burdensome! - John
Yes, its very helpful, exploring all the things people would like to do really carves out the corner cases we need to think about. In that sense, I'm very grateful for the active discussion since it prevents nasty surprises that would happen if those corner cases were discovered too late.
Ciao,
Alexander Wuerstlein.