Re: [PATCH v3 4/4] Allow unprivileged chroot when safe

[Colin Walters <walters@verbum.org>]

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*.