proc map_files entries require CAP_CHECKPOINT_RESTORE in init ns, not current

proc map_files entries require CAP_CHECKPOINT_RESTORE in init ns, not current

[Younes Manton]

Hi,

imachug@yandex.ru testing CRIU noticed that the documentation for
proc's map_files directory with respect to CAP_CHECKPOINT_RESTORE and
namespaces appears to be wrong. The text reads:

> since Linux 5.9, the reading process must have
> either CAP_SYS_ADMIN or CAP_CHECKPOINT_RESTORE in the user
> namespace where it resides.

The reporter noted that the user actually needs the capabilities in
the initial user namespace, not in the namespace the process resides
in. As far as I can tell this appears to be the case.

The text was introduced in 167f94b707148bcd46fe39c7d4ebfada9eed88f6
and refers to kernel commit 12886f8ab10ce6a09af1d92535d49c81aaa215a8.

The code and message in the kernel commit refer to the initial user namespace.

Re: proc map_files entries require CAP_CHECKPOINT_RESTORE in init ns, not current

[Alejandro Colomar]

[-- Attachment #1.1: Type: text/plain, Size: 1007 bytes --]

Hi Younes,

On 11/1/22 17:49, Younes Manton wrote:
> Hi,
> 
> imachug@yandex.ru testing CRIU noticed that the documentation for
> proc's map_files directory with respect to CAP_CHECKPOINT_RESTORE and
> namespaces appears to be wrong. The text reads:
> 
>> since Linux 5.9, the reading process must have
>> either CAP_SYS_ADMIN or CAP_CHECKPOINT_RESTORE in the user
>> namespace where it resides.
> 
> The reporter noted that the user actually needs the capabilities in
> the initial user namespace, not in the namespace the process resides
> in. As far as I can tell this appears to be the case.
> 
> The text was introduced in 167f94b707148bcd46fe39c7d4ebfada9eed88f6
> and refers to kernel commit 12886f8ab10ce6a09af1d92535d49c81aaa215a8.
> 
> The code and message in the kernel commit refer to the initial user namespace.

Could you please write a small program and shell session that demonstrates 
either behavior?


Thanks,

Alex

-- 
<http://www.alejandro-colomar.es/>

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: proc map_files entries require CAP_CHECKPOINT_RESTORE in init ns, not current

[Younes Manton]

On Tue, Nov 1, 2022 at 12:52 PM Alejandro Colomar
<alx.manpages@gmail.com> wrote:
>
> Hi Younes,
>
> On 11/1/22 17:49, Younes Manton wrote:
> > Hi,
> >
> > imachug@yandex.ru testing CRIU noticed that the documentation for
> > proc's map_files directory with respect to CAP_CHECKPOINT_RESTORE and
> > namespaces appears to be wrong. The text reads:
> >
> >> since Linux 5.9, the reading process must have
> >> either CAP_SYS_ADMIN or CAP_CHECKPOINT_RESTORE in the user
> >> namespace where it resides.
> >
> > The reporter noted that the user actually needs the capabilities in
> > the initial user namespace, not in the namespace the process resides
> > in. As far as I can tell this appears to be the case.
> >
> > The text was introduced in 167f94b707148bcd46fe39c7d4ebfada9eed88f6
> > and refers to kernel commit 12886f8ab10ce6a09af1d92535d49c81aaa215a8.
> >
> > The code and message in the kernel commit refer to the initial user namespace.
>
> Could you please write a small program and shell session that demonstrates
> either behavior?
>
>
> Thanks,
>
> Alex
>
> --
> <http://www.alejandro-colomar.es/>

Hi, see below:

$ uname -r
5.15.0-52-generic

$ ./test.sh
+ make rmf
cc rmf.c -o rmf
+ sudo setcap cap_checkpoint_restore-eip ./rmf
+ ./rmf
19582: =
Can't read map_files/ entry: Operation not permitted
+ sudo setcap cap_checkpoint_restore+eip ./rmf
+ ./rmf
19588: cap_checkpoint_restore=ep
+ unshare --user ./rmf
19591: cap_checkpoint_restore=ep
Can't read map_files/ entry: Operation not permitted

$ cat rmf.c
#include <stdlib.h>
#include <stdio.h>
#include <string.h>
#include <sys/types.h>
#include <dirent.h>
#include <sys/stat.h>
#include <unistd.h>

int main(int argc, char **argv)
{
    DIR *mfd;
    struct dirent *mfe;
    struct stat mfstat;
    int ret;

    system("getpcaps $PPID");

    chdir("/proc/self/map_files");
    mfd = opendir(".");
    do {
        mfe = readdir(mfd);
    } while (!strcmp(mfe->d_name, ".") || !strcmp(mfe->d_name, ".."));
    if (ret = stat(mfe->d_name, &mfstat))
        perror("Can't read map_files/ entry");
    closedir(mfd);

    return ret;
}

Re: proc map_files entries require CAP_CHECKPOINT_RESTORE in init ns, not current

[Alejandro Colomar]

[-- Attachment #1.1: Type: text/plain, Size: 2905 bytes --]

Hi Younes,

Sorry for the delay in replying!

On 11/3/22 15:11, Younes Manton wrote:
> On Tue, Nov 1, 2022 at 12:52 PM Alejandro Colomar
> <alx.manpages@gmail.com> wrote:
>>
>> Hi Younes,
>>
>> On 11/1/22 17:49, Younes Manton wrote:
>>> Hi,
>>>
>>> imachug@yandex.ru testing CRIU noticed that the documentation for
>>> proc's map_files directory with respect to CAP_CHECKPOINT_RESTORE and
>>> namespaces appears to be wrong. The text reads:
>>>
>>>> since Linux 5.9, the reading process must have
>>>> either CAP_SYS_ADMIN or CAP_CHECKPOINT_RESTORE in the user
>>>> namespace where it resides.
>>>
>>> The reporter noted that the user actually needs the capabilities in
>>> the initial user namespace, not in the namespace the process resides
>>> in. As far as I can tell this appears to be the case.
>>>
>>> The text was introduced in 167f94b707148bcd46fe39c7d4ebfada9eed88f6
>>> and refers to kernel commit 12886f8ab10ce6a09af1d92535d49c81aaa215a8.
>>>
>>> The code and message in the kernel commit refer to the initial user namespace.
>>
>> Could you please write a small program and shell session that demonstrates
>> either behavior?
>>
>>
>> Thanks,
>>
>> Alex
>>
>> --
>> <http://www.alejandro-colomar.es/>
> 
> Hi, see below:
> 
> $ uname -r
> 5.15.0-52-generic
> 
> $ ./test.sh
> + make rmf
> cc rmf.c -o rmf
> + sudo setcap cap_checkpoint_restore-eip ./rmf
> + ./rmf
> 19582: =
> Can't read map_files/ entry: Operation not permitted
> + sudo setcap cap_checkpoint_restore+eip ./rmf
> + ./rmf
> 19588: cap_checkpoint_restore=ep
> + unshare --user ./rmf
> 19591: cap_checkpoint_restore=ep
> Can't read map_files/ entry: Operation not permitted
> 
> $ cat rmf.c
> #include <stdlib.h>
> #include <stdio.h>
> #include <string.h>
> #include <sys/types.h>
> #include <dirent.h>
> #include <sys/stat.h>
> #include <unistd.h>
> 
> int main(int argc, char **argv)
> {
>      DIR *mfd;
>      struct dirent *mfe;
>      struct stat mfstat;
>      int ret;
> 
>      system("getpcaps $PPID");
> 
>      chdir("/proc/self/map_files");
>      mfd = opendir(".");
>      do {
>          mfe = readdir(mfd);
>      } while (!strcmp(mfe->d_name, ".") || !strcmp(mfe->d_name, ".."));
>      if (ret = stat(mfe->d_name, &mfstat))
>          perror("Can't read map_files/ entry");
>      closedir(mfd);
> 
>      return ret;
> }

Thanks!

Would you please send a patch to the manual page?  You can check 
<https://git.kernel.org/pub/scm/docs/man-pages/man-pages.git/tree/CONTRIBUTING> 
for details on how to do that, or ask me for help if you need.

Ideally, all of the details including the example program that you already 
shared should go into the commit message (or at least the most basic details and 
a link to the mailing list archive for more).

Cheers,

Alex

-- 
<http://www.alejandro-colomar.es/>

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 833 bytes --]

Re: proc map_files entries require CAP_CHECKPOINT_RESTORE in init ns, not current

[Younes Manton]

Hi,

On Sun, Dec 11, 2022 at 12:30 PM Alejandro Colomar
<alx.manpages@gmail.com> wrote:
>
> Hi Younes,
>
> Sorry for the delay in replying!
>
> On 11/3/22 15:11, Younes Manton wrote:
> > On Tue, Nov 1, 2022 at 12:52 PM Alejandro Colomar
> > <alx.manpages@gmail.com> wrote:
> >>
> >> Hi Younes,
> >>
> >> On 11/1/22 17:49, Younes Manton wrote:
> >>> Hi,
> >>>
> >>> imachug@yandex.ru testing CRIU noticed that the documentation for
> >>> proc's map_files directory with respect to CAP_CHECKPOINT_RESTORE and
> >>> namespaces appears to be wrong. The text reads:
> >>>
> >>>> since Linux 5.9, the reading process must have
> >>>> either CAP_SYS_ADMIN or CAP_CHECKPOINT_RESTORE in the user
> >>>> namespace where it resides.
> >>>
> >>> The reporter noted that the user actually needs the capabilities in
> >>> the initial user namespace, not in the namespace the process resides
> >>> in. As far as I can tell this appears to be the case.
> >>>
> >>> The text was introduced in 167f94b707148bcd46fe39c7d4ebfada9eed88f6
> >>> and refers to kernel commit 12886f8ab10ce6a09af1d92535d49c81aaa215a8.
> >>>
> >>> The code and message in the kernel commit refer to the initial user namespace.
> >>
> >> Could you please write a small program and shell session that demonstrates
> >> either behavior?
> >>
> >>
> >> Thanks,
> >>
> >> Alex
> >>
> >> --
> >> <http://www.alejandro-colomar.es/>
> >
> > Hi, see below:
> >
> > $ uname -r
> > 5.15.0-52-generic
> >
> > $ ./test.sh
> > + make rmf
> > cc rmf.c -o rmf
> > + sudo setcap cap_checkpoint_restore-eip ./rmf
> > + ./rmf
> > 19582: =
> > Can't read map_files/ entry: Operation not permitted
> > + sudo setcap cap_checkpoint_restore+eip ./rmf
> > + ./rmf
> > 19588: cap_checkpoint_restore=ep
> > + unshare --user ./rmf
> > 19591: cap_checkpoint_restore=ep
> > Can't read map_files/ entry: Operation not permitted
> >
> > $ cat rmf.c
> > #include <stdlib.h>
> > #include <stdio.h>
> > #include <string.h>
> > #include <sys/types.h>
> > #include <dirent.h>
> > #include <sys/stat.h>
> > #include <unistd.h>
> >
> > int main(int argc, char **argv)
> > {
> >      DIR *mfd;
> >      struct dirent *mfe;
> >      struct stat mfstat;
> >      int ret;
> >
> >      system("getpcaps $PPID");
> >
> >      chdir("/proc/self/map_files");
> >      mfd = opendir(".");
> >      do {
> >          mfe = readdir(mfd);
> >      } while (!strcmp(mfe->d_name, ".") || !strcmp(mfe->d_name, ".."));
> >      if (ret = stat(mfe->d_name, &mfstat))
> >          perror("Can't read map_files/ entry");
> >      closedir(mfd);
> >
> >      return ret;
> > }
>
> Thanks!
>
> Would you please send a patch to the manual page?  You can check
> <https://git.kernel.org/pub/scm/docs/man-pages/man-pages.git/tree/CONTRIBUTING>
> for details on how to do that, or ask me for help if you need.
>
> Ideally, all of the details including the example program that you already
> shared should go into the commit message (or at least the most basic details and
> a link to the mailing list archive for more).
>

Sent to the list with details and example program in the commit
message, subject "[PATCH] proc.5: Fix caps needed to read map_files
contents".

> Cheers,
>
> Alex
>
> --
> <http://www.alejandro-colomar.es/>