On Mon, 2012-01-30 at 15:15 -0800, Andy Lutomirski wrote: > You can accomplish the same thing *without a scary setuid binary*. > The use case doesn't even need a new complicated userspace tool. You > would set up an initscript or some /etc/fstab entries and then: That requires administrative access to the system and custom configuration; if you have that, you could just as easily set up a wrapper script to run sudo + shell script to do whatever you want for example. That's the role schroot fills now - basically pre-canned scripts, but you don't get out of custom configuration or needing root access to set it up. And as I mentioned in https://lkml.org/lkml/2011/12/9/213, it's not as interesting as you might think even in the model of "pre-configure, give out access to regular users", because if you allow uploading .debs, it's just an elaborate root shell. The most interesting thing to me is an entire setup that doesn't require administrative access, so you can do it on any server or workstation, and I have that with linux-user-chroot. > no_new_privs chroot /var/chroot/ubuntu_oneiric/ /bin/bash > > et voila. (Where no_new_privs would be a really simple tool that does > PR_SET_NO_NEW_PRIVS and then execs its argument.) > > Maybe it's just me, but I think this is useful and I would, in fact, > use it in my regular workflow. workflow for what? Building software? Let's try to narrow down the problem we're solving here. It sounds like you're saying "schroot could be implemented with no setuid binary", which I'm not sure is true. The program has a big pile of shell script hooks that are presently run as root - the bind mounts you mention are part of it, but other stuff like synchronizing the NSS database is there too. I guess I'd find this patch a lot more convincing if you had actually written code to use it and in practice found it useful, not just *in theory*. -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html