Messages in this thread | | | From | Andy Lutomirski <> | Date | Mon, 30 Jan 2012 16:13:39 -0800 | Subject | Re: [PATCH v3 4/4] Allow unprivileged chroot when safe |
| |
On Mon, Jan 30, 2012 at 3:55 PM, Colin Walters <walters@verbum.org> 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-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/
| |