Hello Eric,
I think I just understood something. See below.
On 10/9/19 11:01 PM, Michael Kerrisk (man-pages) wrote:
> Hello Eric,
>
> On 10/9/19 6:00 PM, Eric W. Biederman wrote:
>> "Michael Kerrisk (man-pages)" <mtk.manpages@xxxxxxxxx> writes:
>>
>>> Hello Eric,
>>>
>>> Thank you. I was hoping you might jump in on this thread.
>>>
>>> Please see below.
>>>
>>> On 10/9/19 10:46 AM, Eric W. Biederman wrote:
>>>> "Michael Kerrisk (man-pages)" <mtk.manpages@xxxxxxxxx> writes:
>>>>
>>>>> Hello Philipp,
>>>>>
>>>>> My apologies that it has taken a while to reply. (I had been hoping
>>>>> and waiting that a few more people might weigh in on this thread.)
>>>>>
>>>>> On 9/23/19 3:42 PM, Philipp Wendler wrote:
>>>>>> Hello Michael,
>>>>>>
>>>>>> Am 23.09.19 um 14:04 schrieb Michael Kerrisk (man-pages):
>>>>>>
>>>>>>> I'm considering to rewrite these pieces to exactly
>>>>>>> describe what the system call does (which I already
>>>>>>> do in the third paragraph) and remove the "may or may not"
>>>>>>> pieces in the second paragraph. I'd welcome comments
>>>>>>> on making that change.
>>>
>>> What did you think about my proposal above? To put it in context,
>>> this was my initial comment in the mail:
>>>
>>> [[
>>> One area of the page that I'm still not really happy with
>>> is the "vague" wording in the second paragraph and the note
>>> in the third paragraph about the system call possibly
>>> changing. These pieces survive (in somewhat modified form)
>>> from the original page, which was written before the
>>> system call was released, and it seems there was some
>>> question about whether the system call might still change
>>> its behavior with respect to the root directory and current
>>> working directory of other processes. However, after 19
>>> years, nothing has changed, and surely it will not in the
>>> future, since that would constitute an ABI breakage.
>>> I'm considering to rewrite these pieces to exactly
>>> describe what the system call does (which I already
>>> do in the third paragraph) and remove the "may or may not"
>>> pieces in the second paragraph. I'd welcome comments
>>> on making that change.
>>> ]]
>>>
>>> And the second and third paragraphs of the manual page currently
>>> read:
>>>
>>> [[
>>> pivot_root() may or may not change the current root and the cur‐
>>> rent working directory of any processes or threads that use the
>>> old root directory and which are in the same mount namespace as
>>> the caller of pivot_root(). The caller of pivot_root() should
>>> ensure that processes with root or current working directory at
>>> the old root operate correctly in either case. An easy way to
>>> ensure this is to change their root and current working directory
>>> to new_root before invoking pivot_root(). Note also that
>>> pivot_root() may or may not affect the calling process's current
>>> working directory. It is therefore recommended to call chdir("/")
>>> immediately after pivot_root().
>>>
>>> The paragraph above is intentionally vague because at the time
>>> when pivot_root() was first implemented, it was unclear whether
>>> its affect on other process's root and current working directo‐
>>> ries—and the caller's current working directory—might change in
>>> the future. However, the behavior has remained consistent since
>>> this system call was first implemented: pivot_root() changes the
>>> root directory and the current working directory of each process
>>> or thread in the same mount namespace to new_root if they point to
>>> the old root directory. (See also NOTES.) On the other hand,
>>> pivot_root() does not change the caller's current working direc‐
>>> tory (unless it is on the old root directory), and thus it should
>>> be followed by a chdir("/") call.
>>> ]]
>>
>> Apologies I saw that concern I didn't realize it was a questio
>>
>> I think it is very reasonable to remove warning the behavior might
>> change. We have pivot_root(8) in common use that to use it requires
>> the semantic of changing processes other than the current process.
>> Which means any attempt to noticably change the behavior of
>> pivot_root(2) will break userspace.
>
> Thanks for the confirmation that this change would be okay.
> I will make this change soon, unless I hear a counterargument.
>
>> Now the documented semantics in behavior above are not quite what
>> pivot_root(2) does. It walks all processes on the system and if the
>> working directory or the root directory refer to the root mount that is
>> being replaced, then pivot_root(2) will update them.
>>
>> In practice the above is limited to a mount namespace. But something as
>> simple as "cd /proc/<somepid>/root" can allow a process to have a
>> working directory in a different mount namespace.
>
> So, I'm not quite clear. Do you mean that something in the existing
> manual page text should change? If so, could you describe the
> needed change please?
Okay, I had to sleep on this one. I think what you are saying is
that is some process, pidX, in mountns X does a "cd /proc/<pidY>/root"
where pidY is a process in mountns Y, and then some
process in mountns Y does a pivot_root(), the the CWD of pidX will
be changed, even though it is in a different mountns. Right?
Thanks,
Michael
--
Michael Kerrisk
Linux man-pages maintainer; http://www.kernel.org/doc/man-pages/
Linux/UNIX System Programming Training: http://man7.org/training/
