lkml.org 
[lkml]   [2012]   [Jan]   [30]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
From
Date
SubjectRe: [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/

\
 
 \ /
  Last update: 2012-01-31 01:17    [W:0.071 / U:0.064 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site