On Mon, Jan 30, 2012 at 3:55 PM, Colin Walters <walters@xxxxxxxxxx> wrote: > 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. Building software. I run Fedora and I write software and generate binaries that need to work on Ubuntu. So I keep an Ubuntu chroot around. On the occasions when I update the chroot, I have no problem sudoing from the Fedora side (although this is suboptimal). I certainly don't need the NSS databases kept in sync, and I'd rather minimize the complexity of things that run setuid root. no_new_privs chroot /var/chroot/ubuntu /bin/bash is sufficient for my needs. If we could have a full fakeroot-like setup supported, that would be even better. But that isn't likely to happen with a 44-line patch. Like I said, the chroot patch is an example. I think it has enough valid usecases to more than justify its minimal complexity. I also think it's far less important than the core no_new_privs patch, which enables lots of things beyond just chroot. --Andy -- 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
