New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

RFE: nspawn: add warning if /proc instance doesn't match the pidns used by the container #5436

Open
safinaskar opened this Issue Feb 23, 2017 · 24 comments

Comments

6 participants
@safinaskar

safinaskar commented Feb 23, 2017

Submission type

  • Bug report

systemd version the issue has been seen with

232

Used distribution

debian stretch

In case of bug report: Steps to reproduce the problem

I have host system debian stretch amd64 with systemd 232-8. I run on this system:

$ sudo debootstrap --variant=minbase stretch ~/tmp/s http://mirror.yandex.ru/debian
$ sudo chroot ~/tmp/s apt-get install systemd systemd-sysv

As you can see, now I have debian stretch in ~/tmp/s. It has systemd 232-15. Now I type:

$ sudo mount -t proc proc ~/tmp/s/proc
$ sudo systemd-nspawn -D ~/tmp/s /sbin/init

In case of bug report: Expected behaviour you didn't see

systemd-nspawn should run successfully or I should see clear error message, i. e. something like "/proc is mounted"

In case of bug report: Unexpected behaviour you saw

Spawning container s on /home/user/tmp/s.
Press ^] three times within 1s to kill container.
Cannot be run in a chroot() environment.
Freezing execution.

I have chroot environments on my computer. I often mount something to dirs /proc, /dev etc of this chroot environments. And often I occasionally try to systemd-nspawn to this environments. In this case nspawn should either proceed, either give meaningful error message, i. e. "/proc is mounted".

Please, make sure that unrelated error messages doesn't shown in all combinations of mounted special file systems, i. e. /proc, /dev, /dev/pts, /dev/shm, /sys, /tmp, /run .

@falconindy

This comment has been minimized.

Show comment
Hide comment
@falconindy

falconindy Feb 23, 2017

Contributor

It's unclear why you think the error message is inaccurate. It isn't. If you want to run systemd in the chroot, then you need to use the --boot flag to systemd-nspawn.

Contributor

falconindy commented Feb 23, 2017

It's unclear why you think the error message is inaccurate. It isn't. If you want to run systemd in the chroot, then you need to use the --boot flag to systemd-nspawn.

@safinaskar

This comment has been minimized.

Show comment
Hide comment
@safinaskar

safinaskar Feb 23, 2017

@falconindy, you didn't understand me. I try to explain again. I have my host system. Host system is running systemd (but this is not important for this bug report). I have dir ~/tmp/s with another system inside it. This second system has systemd, too. I call this (second) system "chroot environment" because it can enter it using "chroot ~/tmp/s". Other way to enter it is "systemd-nspawn -D ~/tmp/s".

Then I try to enter it using "systemd-nspawn -D ~/tmp/s /sbin/init". This is perfectly normal way to run this system. (/sbin/init is linked to systemd inside this system.) And this command works. But if /proc (i. e. ~/tmp/s/proc) is premounted, systemd-nspawn doesn't work. It fails with unrelated error message.

"--boot" just automatically searchs for init program (as it seems from man page).

I want error message to show cause of error. Cause is mounted /proc. How to force right error message to appear? Well, I have one possible solution: systemd-nspawn should check whatever kernel file systems mounted before running container.

safinaskar commented Feb 23, 2017

@falconindy, you didn't understand me. I try to explain again. I have my host system. Host system is running systemd (but this is not important for this bug report). I have dir ~/tmp/s with another system inside it. This second system has systemd, too. I call this (second) system "chroot environment" because it can enter it using "chroot ~/tmp/s". Other way to enter it is "systemd-nspawn -D ~/tmp/s".

Then I try to enter it using "systemd-nspawn -D ~/tmp/s /sbin/init". This is perfectly normal way to run this system. (/sbin/init is linked to systemd inside this system.) And this command works. But if /proc (i. e. ~/tmp/s/proc) is premounted, systemd-nspawn doesn't work. It fails with unrelated error message.

"--boot" just automatically searchs for init program (as it seems from man page).

I want error message to show cause of error. Cause is mounted /proc. How to force right error message to appear? Well, I have one possible solution: systemd-nspawn should check whatever kernel file systems mounted before running container.

@safinaskar

This comment has been minimized.

Show comment
Hide comment
@safinaskar

safinaskar Feb 23, 2017

I already reported similar bug before: #3695 . So, errors of this class continue to appear, this is bad. Fix them for all combinations of special file systems!

safinaskar commented Feb 23, 2017

I already reported similar bug before: #3695 . So, errors of this class continue to appear, this is bad. Fix them for all combinations of special file systems!

@poettering

This comment has been minimized.

Show comment
Hide comment
@poettering

poettering Feb 23, 2017

Member

@safinaskar can you test this again with current git?

Member

poettering commented Feb 23, 2017

@safinaskar can you test this again with current git?

@martinpitt

This comment has been minimized.

Show comment
Hide comment
@martinpitt

martinpitt Feb 23, 2017

Contributor

systemd-nspawn -D ~/tmp/s /sbin/init. This is perfectly normal way to run this system.

Is it? I thought this should be spelled systemd-nspawn -D ~/tmp/s -b?

Contributor

martinpitt commented Feb 23, 2017

systemd-nspawn -D ~/tmp/s /sbin/init. This is perfectly normal way to run this system.

Is it? I thought this should be spelled systemd-nspawn -D ~/tmp/s -b?

@floppym

This comment has been minimized.

Show comment
Hide comment
@floppym

floppym Feb 23, 2017

Contributor

Is it? I thought this should be spelled systemd-nspawn -D ~/tmp/s -b?

As has been previously stated, passing -b (--boot) to systemd-nspawn simply causes it to search for an init program. Naming the init program directly has the same effect.

It also allows the init program to be selected explicitly when more than one is installed, as would be the case for a hybrid sysvinit/systemd image.

Contributor

floppym commented Feb 23, 2017

Is it? I thought this should be spelled systemd-nspawn -D ~/tmp/s -b?

As has been previously stated, passing -b (--boot) to systemd-nspawn simply causes it to search for an init program. Naming the init program directly has the same effect.

It also allows the init program to be selected explicitly when more than one is installed, as would be the case for a hybrid sysvinit/systemd image.

@safinaskar

This comment has been minimized.

Show comment
Hide comment
@safinaskar

safinaskar Feb 23, 2017

@falconindy, @martinpitt, I just tried sudo systemd-nspawn -bD ~/tmp/ss instead of sudo systemd-nspawn -D ~/tmp/ss /sbin/init and reproduced the bug

safinaskar commented Feb 23, 2017

@falconindy, @martinpitt, I just tried sudo systemd-nspawn -bD ~/tmp/ss instead of sudo systemd-nspawn -D ~/tmp/ss /sbin/init and reproduced the bug

@safinaskar

This comment has been minimized.

Show comment
Hide comment
@safinaskar

safinaskar Feb 24, 2017

@poettering, current git (ecc0eab) seems not to have this bug. ~/tmp/ss just successfully boots. But now I see another bug. If I premount proc, run container and then run "poweroff" inside this container[1], then I see: "Running in chroot, ignoring request."

Let me say my hypothesis, why this happens (of course, I could be wrong). I premount /proc, run container using nspawn. Nspawn just keeps this /proc as is. So, it leaves broken /proc. Then container boots, I type "poweroff" into it, "poweroff" notices that / and /proc/1/root/ are not same inodes. And then "poweroff" prints error message. So, nspawn should not leave /proc as is. It should notice that /proc already mounted and give meaningful error message: "/proc is mounted". Same applies to all special file systems (/proc, /dev, /dev/pts, /dev/shm, /sys, /run, /tmp and so on). If nspawn notices that some of them are mounted, it should either give meaningful error message, either proceed as usual if nspawn is 100%-sure that leaving this mount point as is will not cause any errors.

[1] This container have systemd 232 from debian (232-18) and systemd ecc0eab in /opt/systemd-ecc0eab247da25a6767ccabd2162a4d03de6ee8c. Also it have package systemd-sysv 232-18 from debian. When I said "poweroff" I mean "poweroff" from this systemd-sysv

safinaskar commented Feb 24, 2017

@poettering, current git (ecc0eab) seems not to have this bug. ~/tmp/ss just successfully boots. But now I see another bug. If I premount proc, run container and then run "poweroff" inside this container[1], then I see: "Running in chroot, ignoring request."

Let me say my hypothesis, why this happens (of course, I could be wrong). I premount /proc, run container using nspawn. Nspawn just keeps this /proc as is. So, it leaves broken /proc. Then container boots, I type "poweroff" into it, "poweroff" notices that / and /proc/1/root/ are not same inodes. And then "poweroff" prints error message. So, nspawn should not leave /proc as is. It should notice that /proc already mounted and give meaningful error message: "/proc is mounted". Same applies to all special file systems (/proc, /dev, /dev/pts, /dev/shm, /sys, /run, /tmp and so on). If nspawn notices that some of them are mounted, it should either give meaningful error message, either proceed as usual if nspawn is 100%-sure that leaving this mount point as is will not cause any errors.

[1] This container have systemd 232 from debian (232-18) and systemd ecc0eab in /opt/systemd-ecc0eab247da25a6767ccabd2162a4d03de6ee8c. Also it have package systemd-sysv 232-18 from debian. When I said "poweroff" I mean "poweroff" from this systemd-sysv

@safinaskar

This comment has been minimized.

Show comment
Hide comment
@safinaskar

safinaskar Feb 24, 2017

When I performed my tests with ecc0eab, I used it both as nspawn and as init system inside container. I installed it into /opt/systemd-ecc0eab247da25a6767ccabd2162a4d03de6ee8c on both systems and typed: sudo /opt/systemd-ecc0eab247da25a6767ccabd2162a4d03de6ee8c/bin/systemd-nspawn -D ~/tmp/ss /opt/systemd-ecc0eab247da25a6767ccabd2162a4d03de6ee8c/lib/systemd/systemd

safinaskar commented Feb 24, 2017

When I performed my tests with ecc0eab, I used it both as nspawn and as init system inside container. I installed it into /opt/systemd-ecc0eab247da25a6767ccabd2162a4d03de6ee8c on both systems and typed: sudo /opt/systemd-ecc0eab247da25a6767ccabd2162a4d03de6ee8c/bin/systemd-nspawn -D ~/tmp/ss /opt/systemd-ecc0eab247da25a6767ccabd2162a4d03de6ee8c/lib/systemd/systemd

@poettering

This comment has been minimized.

Show comment
Hide comment
@poettering

poettering Feb 24, 2017

Member

@safinaskar hmm, so, in your setup, is /proc/1 actually referring to the container's PID 1? or the host's PID 1?

The /proc/1/root == / check validates whether the root directory of the "reboot" command matches the root directory of PID 1, and assumes that chroot()ing is used when that does not match... I am not sure I grok why this check wouldn't work for your procfs setup, unless the PID 1 visible in your case is actually the one from the host, not the container.

In the container, what's the output of stat /proc/1/stat /?

Are you using user namespacing?

Member

poettering commented Feb 24, 2017

@safinaskar hmm, so, in your setup, is /proc/1 actually referring to the container's PID 1? or the host's PID 1?

The /proc/1/root == / check validates whether the root directory of the "reboot" command matches the root directory of PID 1, and assumes that chroot()ing is used when that does not match... I am not sure I grok why this check wouldn't work for your procfs setup, unless the PID 1 visible in your case is actually the one from the host, not the container.

In the container, what's the output of stat /proc/1/stat /?

Are you using user namespacing?

@safinaskar

This comment has been minimized.

Show comment
Hide comment
@safinaskar

safinaskar Feb 24, 2017

@poettering, again: I premounted /proc before running container. Of course, after this strange step all sorts of strange things will appear.

I performed some tests with clone(CLONE_NEWPID). And I see the following: if some proc file system is already mounted before starting of NEWPID process, then this new process will see external processes in this proc file system. But if this new process performed mounting itself, it will see only "its" processes in this proc.

So, we leave external /proc and so /proc/1 is referring to external PID 1.

See log: https://zerobin.net/?353e79a1cb1d686c#qE6OAsJWj+8gshUzbXF5S5H2Agpl4Hre0SFVESA7hmk= .

I run stat /proc/1/stat /, also I run stat /proc/1/root /proc/1/root/. Then I unmounted /proc and mounted it again (this time inside of PID namespace), notice that stat /proc/1/root/ output changed.

Are you using user namespacing?

No.

I hope now you see that premounted file systems are evil and we should probably detect all them and give error message.

I wrote simple util to demonstrate idea: https://zerobin.net/?157c4ef880b51028#nqRE+ASeUkIRCQiRxkh1bL8f/arxO38L2NlEXqFdJSg= . Here I show /proc manipulations: https://zerobin.net/?4e0adabe5e2e4de7#H9Mx1404gcNfN+6ZbZDcShlMJQ6uIYTYapgHDPisk+Q= .

safinaskar commented Feb 24, 2017

@poettering, again: I premounted /proc before running container. Of course, after this strange step all sorts of strange things will appear.

I performed some tests with clone(CLONE_NEWPID). And I see the following: if some proc file system is already mounted before starting of NEWPID process, then this new process will see external processes in this proc file system. But if this new process performed mounting itself, it will see only "its" processes in this proc.

So, we leave external /proc and so /proc/1 is referring to external PID 1.

See log: https://zerobin.net/?353e79a1cb1d686c#qE6OAsJWj+8gshUzbXF5S5H2Agpl4Hre0SFVESA7hmk= .

I run stat /proc/1/stat /, also I run stat /proc/1/root /proc/1/root/. Then I unmounted /proc and mounted it again (this time inside of PID namespace), notice that stat /proc/1/root/ output changed.

Are you using user namespacing?

No.

I hope now you see that premounted file systems are evil and we should probably detect all them and give error message.

I wrote simple util to demonstrate idea: https://zerobin.net/?157c4ef880b51028#nqRE+ASeUkIRCQiRxkh1bL8f/arxO38L2NlEXqFdJSg= . Here I show /proc manipulations: https://zerobin.net/?4e0adabe5e2e4de7#H9Mx1404gcNfN+6ZbZDcShlMJQ6uIYTYapgHDPisk+Q= .

@evverx

This comment has been minimized.

Show comment
Hide comment
@evverx

evverx Feb 24, 2017

Member

I hope now you see that premounted file systems are evil

Actually, no.

mount -t proc proc container_root/proc
systemd-nspawn -D ./container_root --share-system

is a pretty legal use case

Well, I have one possible solution: systemd-nspawn should check whatever kernel file systems mounted before running container

What do you mean by "kernel file systems"? proc, cgroup, cgroup2, sysfs, devtmpfs or anything else?

and we should probably detect all them and give error message

This doesn't make sense sometimes:

  • --share-system
  • SYSTEMD_NSPAWN_SHARE_NS_PID=yes ...
  • SYSTEMD_NSPAWN_SHARE_SYSTEM=yes ...

Other ideas?

Member

evverx commented Feb 24, 2017

I hope now you see that premounted file systems are evil

Actually, no.

mount -t proc proc container_root/proc
systemd-nspawn -D ./container_root --share-system

is a pretty legal use case

Well, I have one possible solution: systemd-nspawn should check whatever kernel file systems mounted before running container

What do you mean by "kernel file systems"? proc, cgroup, cgroup2, sysfs, devtmpfs or anything else?

and we should probably detect all them and give error message

This doesn't make sense sometimes:

  • --share-system
  • SYSTEMD_NSPAWN_SHARE_NS_PID=yes ...
  • SYSTEMD_NSPAWN_SHARE_SYSTEM=yes ...

Other ideas?

@safinaskar

This comment has been minimized.

Show comment
Hide comment
@safinaskar

safinaskar Feb 25, 2017

is a pretty legal use case

At least, please, give a warning (or error) if there is no SYSTEMD_NSPAWN_SHARE_NS_PID or similar. You can put a warning to nspawn or to PID 1.

What do you mean by "kernel file systems"?

I use the following file systems in my workflow and in my scripts: /proc, /dev, /dev/pts, /dev/shm, /sys, /run, /tmp (yes, "kernel file systems" here is wrong term, I just mean "file systems usually mounted in running system"). This means I often mount them, then forget about them, then try to nspawn to the container. Of course, final list of file systems is up to systemd developers.

And I don't mean systemd should give an error if any of them is mounted. It should give an error is some of them is mounted which can cause some bad things. For example, mounted /proc, as we saw, causes problems with poweroff.

safinaskar commented Feb 25, 2017

is a pretty legal use case

At least, please, give a warning (or error) if there is no SYSTEMD_NSPAWN_SHARE_NS_PID or similar. You can put a warning to nspawn or to PID 1.

What do you mean by "kernel file systems"?

I use the following file systems in my workflow and in my scripts: /proc, /dev, /dev/pts, /dev/shm, /sys, /run, /tmp (yes, "kernel file systems" here is wrong term, I just mean "file systems usually mounted in running system"). This means I often mount them, then forget about them, then try to nspawn to the container. Of course, final list of file systems is up to systemd developers.

And I don't mean systemd should give an error if any of them is mounted. It should give an error is some of them is mounted which can cause some bad things. For example, mounted /proc, as we saw, causes problems with poweroff.

@evverx

This comment has been minimized.

Show comment
Hide comment
@evverx

evverx Feb 25, 2017

Member

The proc-filesystem doesn't cause problems if your tools always use /proc/self.

For example

mount -t proc proc container_root/proc
systemd-nspawn -D container_root cat /proc/self/cmdline

works fine. Why should we give an error?

It should give an error is some of them is mounted which can cause some bad things

Well, I'm not sure how to properly detect that.

Member

evverx commented Feb 25, 2017

The proc-filesystem doesn't cause problems if your tools always use /proc/self.

For example

mount -t proc proc container_root/proc
systemd-nspawn -D container_root cat /proc/self/cmdline

works fine. Why should we give an error?

It should give an error is some of them is mounted which can cause some bad things

Well, I'm not sure how to properly detect that.

@safinaskar

This comment has been minimized.

Show comment
Hide comment
@safinaskar

safinaskar Feb 25, 2017

The proc-filesystem doesn't cause problems if your tools always use /proc/self.

Yes. But what if they don't use? Say, ps? Already mentioned poweroff?

safinaskar commented Feb 25, 2017

The proc-filesystem doesn't cause problems if your tools always use /proc/self.

Yes. But what if they don't use? Say, ps? Already mentioned poweroff?

@poettering

This comment has been minimized.

Show comment
Hide comment
@poettering

poettering Feb 26, 2017

Member

At least, please, give a warning (or error) if there is no SYSTEMD_NSPAWN_SHARE_NS_PID or similar. You can put a warning to nspawn or to PID 1.

Well, this are all features not documented in the man pages, for a reason: we don't fully support them, and YMMV. You should know what you do when you use them, they are not supposed to be discoverable and show friendly warnings. I am not convinced we should change this.

Member

poettering commented Feb 26, 2017

At least, please, give a warning (or error) if there is no SYSTEMD_NSPAWN_SHARE_NS_PID or similar. You can put a warning to nspawn or to PID 1.

Well, this are all features not documented in the man pages, for a reason: we don't fully support them, and YMMV. You should know what you do when you use them, they are not supposed to be discoverable and show friendly warnings. I am not convinced we should change this.

@evverx

This comment has been minimized.

Show comment
Hide comment
@evverx

evverx Feb 27, 2017

Member

@poettering , this issue is not about friendly warnings. The problem is

mount -t proc proc container/proc
systemd-nspawn -D container -b /usr/lib/systemd/systemd

We shouldn't allow that.

But we should allow

mount -t proc proc container/proc
systemd-nspawn -D container cat /proc/self/cmdline
systemd-nspawn -D container --share-system ...
and so on
Member

evverx commented Feb 27, 2017

@poettering , this issue is not about friendly warnings. The problem is

mount -t proc proc container/proc
systemd-nspawn -D container -b /usr/lib/systemd/systemd

We shouldn't allow that.

But we should allow

mount -t proc proc container/proc
systemd-nspawn -D container cat /proc/self/cmdline
systemd-nspawn -D container --share-system ...
and so on
@evverx

This comment has been minimized.

Show comment
Hide comment
@evverx

evverx Feb 27, 2017

Member

We shouldn't allow that.

Because it's a mess. For example

container# ps -C systemd-journald
  PID TTY          TIME CMD
  351 ?        00:00:00 systemd-journal
23774 ?        00:00:00 systemd-journal

container# cat /sys/fs/cgroup/systemd/system.slice/systemd-journald.service/tasks
15

container# ps 15
  PID TTY      STAT   TIME COMMAND
   15 ?        S      0:00 [cpuhp/1]
Member

evverx commented Feb 27, 2017

We shouldn't allow that.

Because it's a mess. For example

container# ps -C systemd-journald
  PID TTY          TIME CMD
  351 ?        00:00:00 systemd-journal
23774 ?        00:00:00 systemd-journal

container# cat /sys/fs/cgroup/systemd/system.slice/systemd-journald.service/tasks
15

container# ps 15
  PID TTY      STAT   TIME COMMAND
   15 ?        S      0:00 [cpuhp/1]
@poettering

This comment has been minimized.

Show comment
Hide comment
@poettering

poettering Feb 27, 2017

Member

@evverx i figure a warning if procfs is not from the pid namespace of the container would indeed be good.

I wonder if there's a nice way to determine whether a specific procfs instance belongs to a specific pidns...

Member

poettering commented Feb 27, 2017

@evverx i figure a warning if procfs is not from the pid namespace of the container would indeed be good.

I wonder if there's a nice way to determine whether a specific procfs instance belongs to a specific pidns...

@poettering poettering changed the title from "systemd-nspawn -D ~/tmp/s /sbin/init" says: "Cannot be run in a chroot() environment." to RFE: nspawn: add warning if /proc instance doesn't match the pidns used by the container Feb 27, 2017

@evverx

This comment has been minimized.

Show comment
Hide comment
@evverx

evverx Feb 27, 2017

Member

i figure a warning if procfs is not from the pid namespace of the container would indeed be good.

This doesn't help to prevent a mess.

I think we can add a sanity check to src/core/main.c. Something like

pid = getpid()
readlink("/proc/self", &val)
if pid != parse_pid(val) { 
/* 
    something went wrong.
    we shouldn't boot (or we should mount -t proc proc /proc)
*/ 
}
Member

evverx commented Feb 27, 2017

i figure a warning if procfs is not from the pid namespace of the container would indeed be good.

This doesn't help to prevent a mess.

I think we can add a sanity check to src/core/main.c. Something like

pid = getpid()
readlink("/proc/self", &val)
if pid != parse_pid(val) { 
/* 
    something went wrong.
    we shouldn't boot (or we should mount -t proc proc /proc)
*/ 
}
@poettering

This comment has been minimized.

Show comment
Hide comment
@poettering

poettering Feb 27, 2017

Member

indeed! that would make sense!

Member

poettering commented Feb 27, 2017

indeed! that would make sense!

@safinaskar

This comment has been minimized.

Show comment
Hide comment
@safinaskar

safinaskar Feb 28, 2017

@poettering

i figure a warning if procfs is not from the pid namespace of the container would indeed be good.

It would be simpler to give error if any procfs is premounted (also, i think it should be error, warning can be ignored by user and this will cause, say, non-working poweroff)

@evverx

I think we can add a sanity check to src/core/main.c

So, you suggest adding it to PID 1? But what if systemd-nspawn -D ~/tmp/ss ps? We should add the check to systemd-nspawn (adding it to PID 1 is also good idea, for example, for using systemd with outer container solutions).

pid = getpid()
readlink("/proc/self", &val)
if pid != parse_pid(val)

This code will not go as general method for determining is this procfs match our PID namespace. Because one process can have equal PIDs in two different PID namespaces. But this method will probably (probably! check all conditionals!) go if we know we are PID 1. In this case we should just

readlink("/proc/self", &val)
if (parse_pid (val) != 1)

safinaskar commented Feb 28, 2017

@poettering

i figure a warning if procfs is not from the pid namespace of the container would indeed be good.

It would be simpler to give error if any procfs is premounted (also, i think it should be error, warning can be ignored by user and this will cause, say, non-working poweroff)

@evverx

I think we can add a sanity check to src/core/main.c

So, you suggest adding it to PID 1? But what if systemd-nspawn -D ~/tmp/ss ps? We should add the check to systemd-nspawn (adding it to PID 1 is also good idea, for example, for using systemd with outer container solutions).

pid = getpid()
readlink("/proc/self", &val)
if pid != parse_pid(val)

This code will not go as general method for determining is this procfs match our PID namespace. Because one process can have equal PIDs in two different PID namespaces. But this method will probably (probably! check all conditionals!) go if we know we are PID 1. In this case we should just

readlink("/proc/self", &val)
if (parse_pid (val) != 1)
@evverx

This comment has been minimized.

Show comment
Hide comment
@evverx

evverx Feb 28, 2017

Member

It would be simpler to give error if any procfs is premounted

It would be simpler to umount your /proc. Also, do you know about unshare -m bash -c 'mount ...; chroot ...;'?

But what if systemd-nspawn -D ~/tmp/ss ps?

mount -t proc ... && systemd-nspawn -D ~/tmp/ss ps is a strange way to list your processes. It's not totally wrong.

also, i think it should be error

No, it shouldn't. We shouldn't break legal scripts.

Member

evverx commented Feb 28, 2017

It would be simpler to give error if any procfs is premounted

It would be simpler to umount your /proc. Also, do you know about unshare -m bash -c 'mount ...; chroot ...;'?

But what if systemd-nspawn -D ~/tmp/ss ps?

mount -t proc ... && systemd-nspawn -D ~/tmp/ss ps is a strange way to list your processes. It's not totally wrong.

also, i think it should be error

No, it shouldn't. We shouldn't break legal scripts.

@safinaskar

This comment has been minimized.

Show comment
Hide comment
@safinaskar

safinaskar Feb 28, 2017

Also, do you know about unshare -m bash -c 'mount ...; chroot ...;'?

Wow, thanks! :)

safinaskar commented Feb 28, 2017

Also, do you know about unshare -m bash -c 'mount ...; chroot ...;'?

Wow, thanks! :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment