On Mon, Oct 20, 2014 at 11:17 AM, Rob Landley <[email protected]> wrote:
> On 10/20/14 11:28, Andy Lutomirski wrote:
>> On Sun, Oct 19, 2014 at 6:53 PM, Rob Landley <[email protected]> wrote:
>>> On 10/19/14 18:13, Andy Lutomirski wrote:
>>>>>> This implements all of the namespace parts of nsenter, but UID and GID
>>>>>> switching are missing, as are -r and -w (both because they're not
>>>>>> strictly
>>>>>> necessary and because the nsenter manpage has an insufficient
>>>>>> description of how they work).
>>>
>>> It looks like -r is just chroot and -w is just chdir.
>>
>> I doubt that.
>
> Looks like it to me.
Grr. I typed "I doubt that" in the wrong place, because gmail. I
really need to stop using gmail.
>
>>>
>>> Except that it's not chroot, it's pivot_root in the new namespace:
>>
>> I doubt that. pivot_root edits the namespace, and setns will set the
>> root to the (pivoted) ns root.
>
> It's an implementation detail, the chroot is done with pivot_root
> because otherwise you haven't actually edited the namespace and you wind
> up able to escape it by moving "/" under the current directory and doing
> cd ../../../../.. back up to the real / (then chroot(".") to move / again).
Sure, but nsenter -r had better not call pivot_root, because it will
affect other things in the namespace.
>
>> The parts that I thought were unclear were:
>>
>> 1. What happens if -r is passed a relative path?
>
> You resolve it in the old namespace, just like with chroot.
So you end up in one ns but with your root in a different ns? That
seems insane. (Yes, this is what util-linux seems to do.) (As the
discoverer of many of the known security bugs in user namespaces, I am
far too familiar with the oddball semantics of this stuff.)
>
>> 2. What is the working directory if -r is used and -w is not used?
>
> It's / in the new namespace, just like chroot.
>
>> 3. What happens if -w is passed a relative path?
>
> My guess would be you resolve it in the new namespace, but I'd probably
> want to try the old command to see what it does and make sure.
>
>> On inspection of the source, if -r and -w have arguments, then they
>> are interpreted *prior to* the setns calls. I strongly suggest not
>> implementing that part of nsenter -- I think that's garbage.
>
> The -r argument kinda has to be prior to the setns call. The -w behavior
> has arguments both ways, and I can see the point of making -r and -w
> behave the same way. (Basically "we interpret -w before -r".)
But, IIUC, doing nsenter -t PID -r PATH -m (where PATH isn't a /proc
symlink) will end up changing the mount namespace and immediately
chrooting out of the mount namespace. The kernel allows this with
somewhat questionable semantics. The only sensible uses in my mind
are to use -r with no argument while also using -t and -m or to use -r
with any argument when not using -m.
Anyway, I guess there's no real harm in emulating util-linux faithfully.
>
>> That being said, my code has a bug: I should open all the ns fds prior
>> to setnsing any of them. Otherwise some of the setns calls may drop
>> required privilege or lose access to the filesystem outright.
>
> I'm 2/3 through a cleanup, I can do that too.
>
> (Implementing sed's been taking up most of my time the past week. I
> should check in a checkpoint of that...)
>
>> --Andy
>
> Rob
--
Andy Lutomirski
AMA Capital Management, LLC
_______________________________________________
Toybox mailing list
[email protected]
http://lists.landley.net/listinfo.cgi/toybox-landley.net
