Is it possible to run a process in chroot with virtual /proc filesystem under Linux?
up vote
1
down vote
favorite
I need to run a process in a chroot with a virtual /proc filesystem, so the process is unable to get access to other processes running on the same host. The process must be run under root and have full access to files in chroot. Also any changes to the filesystem must be preserved in the chrooted directory.
Is it even possible?
linux linux-kernel chroot proc
add a comment |
up vote
1
down vote
favorite
I need to run a process in a chroot with a virtual /proc filesystem, so the process is unable to get access to other processes running on the same host. The process must be run under root and have full access to files in chroot. Also any changes to the filesystem must be preserved in the chrooted directory.
Is it even possible?
linux linux-kernel chroot proc
1
Any particular reason for trying to achieve such behavior?
– ddnomad
Mar 21 '17 at 1:31
a VM or LXC container will give you a real-looking/proc
without actually being the host's/proc
.
– quixotic
Mar 21 '17 at 4:09
add a comment |
up vote
1
down vote
favorite
up vote
1
down vote
favorite
I need to run a process in a chroot with a virtual /proc filesystem, so the process is unable to get access to other processes running on the same host. The process must be run under root and have full access to files in chroot. Also any changes to the filesystem must be preserved in the chrooted directory.
Is it even possible?
linux linux-kernel chroot proc
I need to run a process in a chroot with a virtual /proc filesystem, so the process is unable to get access to other processes running on the same host. The process must be run under root and have full access to files in chroot. Also any changes to the filesystem must be preserved in the chrooted directory.
Is it even possible?
linux linux-kernel chroot proc
linux linux-kernel chroot proc
edited Mar 21 '17 at 2:09
user unknown
1,4441123
1,4441123
asked Mar 21 '17 at 0:30
user4674453
61
61
1
Any particular reason for trying to achieve such behavior?
– ddnomad
Mar 21 '17 at 1:31
a VM or LXC container will give you a real-looking/proc
without actually being the host's/proc
.
– quixotic
Mar 21 '17 at 4:09
add a comment |
1
Any particular reason for trying to achieve such behavior?
– ddnomad
Mar 21 '17 at 1:31
a VM or LXC container will give you a real-looking/proc
without actually being the host's/proc
.
– quixotic
Mar 21 '17 at 4:09
1
1
Any particular reason for trying to achieve such behavior?
– ddnomad
Mar 21 '17 at 1:31
Any particular reason for trying to achieve such behavior?
– ddnomad
Mar 21 '17 at 1:31
a VM or LXC container will give you a real-looking
/proc
without actually being the host's /proc
.– quixotic
Mar 21 '17 at 4:09
a VM or LXC container will give you a real-looking
/proc
without actually being the host's /proc
.– quixotic
Mar 21 '17 at 4:09
add a comment |
2 Answers
2
active
oldest
votes
up vote
0
down vote
It is possible to mount /proc in a chroot environment - see this answer for more on that.
I would have concerns that the program would not be able to get access to other processes as much (if not all) of this information can be accessed through /proc (/proc/[pid number] will give you access to this ).
Its unclear what you mean by "changes to the filesystem", but if these changes are to the filesystem excluding special bits like /proc, /dev/ etc, these will stay in the chroot.
mounting the real/proc
in the chroot is pretty much exactly what the question is trying to avoid.
– quixotic
Mar 21 '17 at 4:00
@quixotic - if thats the case, the answer is "no" - unless a lot more information given as to what specific parts of /proc are needed. Rereading the question, I wonder if the understanding of filesystems is correct - as in does "changes to the filesystem must be preserved" imply access to files outside the scope of the directories under the chroot jail.
– davidgo
Mar 21 '17 at 4:06
agree that doesn't entirely make sense -- it could be assuming a read-only base for the chroot, like docker or snapshot-able VM images or running the chroot in a loop-mounted ISO image or ...
– quixotic
Mar 21 '17 at 4:14
> Its unclear what you mean by "changes to the filesystem" That was to avoid docker fans to flood the topic :) What I really need is to be able to install any package, which pulls a lot of dependencies in that way it won't pollute the system, and be usable in the shell like it is installed in /usr/bin. So I would like it to use main root, but all the changes it produces, including dependencies, logs, etc. to be stored in separate directory. I want it to know nothing about root system, and the processes it's running, as it won't work smoothly.
– user4674453
Mar 21 '17 at 22:36
add a comment |
up vote
0
down vote
You can accomplish this using Linux namespaces. Containers (Docker, lxc) are made out of those. man unshare
is Your friend.
Beware that attacker can easily escape chroot
if You use it improperly. Read up on this before using it. You have been warned.
add a comment |
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
0
down vote
It is possible to mount /proc in a chroot environment - see this answer for more on that.
I would have concerns that the program would not be able to get access to other processes as much (if not all) of this information can be accessed through /proc (/proc/[pid number] will give you access to this ).
Its unclear what you mean by "changes to the filesystem", but if these changes are to the filesystem excluding special bits like /proc, /dev/ etc, these will stay in the chroot.
mounting the real/proc
in the chroot is pretty much exactly what the question is trying to avoid.
– quixotic
Mar 21 '17 at 4:00
@quixotic - if thats the case, the answer is "no" - unless a lot more information given as to what specific parts of /proc are needed. Rereading the question, I wonder if the understanding of filesystems is correct - as in does "changes to the filesystem must be preserved" imply access to files outside the scope of the directories under the chroot jail.
– davidgo
Mar 21 '17 at 4:06
agree that doesn't entirely make sense -- it could be assuming a read-only base for the chroot, like docker or snapshot-able VM images or running the chroot in a loop-mounted ISO image or ...
– quixotic
Mar 21 '17 at 4:14
> Its unclear what you mean by "changes to the filesystem" That was to avoid docker fans to flood the topic :) What I really need is to be able to install any package, which pulls a lot of dependencies in that way it won't pollute the system, and be usable in the shell like it is installed in /usr/bin. So I would like it to use main root, but all the changes it produces, including dependencies, logs, etc. to be stored in separate directory. I want it to know nothing about root system, and the processes it's running, as it won't work smoothly.
– user4674453
Mar 21 '17 at 22:36
add a comment |
up vote
0
down vote
It is possible to mount /proc in a chroot environment - see this answer for more on that.
I would have concerns that the program would not be able to get access to other processes as much (if not all) of this information can be accessed through /proc (/proc/[pid number] will give you access to this ).
Its unclear what you mean by "changes to the filesystem", but if these changes are to the filesystem excluding special bits like /proc, /dev/ etc, these will stay in the chroot.
mounting the real/proc
in the chroot is pretty much exactly what the question is trying to avoid.
– quixotic
Mar 21 '17 at 4:00
@quixotic - if thats the case, the answer is "no" - unless a lot more information given as to what specific parts of /proc are needed. Rereading the question, I wonder if the understanding of filesystems is correct - as in does "changes to the filesystem must be preserved" imply access to files outside the scope of the directories under the chroot jail.
– davidgo
Mar 21 '17 at 4:06
agree that doesn't entirely make sense -- it could be assuming a read-only base for the chroot, like docker or snapshot-able VM images or running the chroot in a loop-mounted ISO image or ...
– quixotic
Mar 21 '17 at 4:14
> Its unclear what you mean by "changes to the filesystem" That was to avoid docker fans to flood the topic :) What I really need is to be able to install any package, which pulls a lot of dependencies in that way it won't pollute the system, and be usable in the shell like it is installed in /usr/bin. So I would like it to use main root, but all the changes it produces, including dependencies, logs, etc. to be stored in separate directory. I want it to know nothing about root system, and the processes it's running, as it won't work smoothly.
– user4674453
Mar 21 '17 at 22:36
add a comment |
up vote
0
down vote
up vote
0
down vote
It is possible to mount /proc in a chroot environment - see this answer for more on that.
I would have concerns that the program would not be able to get access to other processes as much (if not all) of this information can be accessed through /proc (/proc/[pid number] will give you access to this ).
Its unclear what you mean by "changes to the filesystem", but if these changes are to the filesystem excluding special bits like /proc, /dev/ etc, these will stay in the chroot.
It is possible to mount /proc in a chroot environment - see this answer for more on that.
I would have concerns that the program would not be able to get access to other processes as much (if not all) of this information can be accessed through /proc (/proc/[pid number] will give you access to this ).
Its unclear what you mean by "changes to the filesystem", but if these changes are to the filesystem excluding special bits like /proc, /dev/ etc, these will stay in the chroot.
answered Mar 21 '17 at 3:13
davidgo
41.4k74985
41.4k74985
mounting the real/proc
in the chroot is pretty much exactly what the question is trying to avoid.
– quixotic
Mar 21 '17 at 4:00
@quixotic - if thats the case, the answer is "no" - unless a lot more information given as to what specific parts of /proc are needed. Rereading the question, I wonder if the understanding of filesystems is correct - as in does "changes to the filesystem must be preserved" imply access to files outside the scope of the directories under the chroot jail.
– davidgo
Mar 21 '17 at 4:06
agree that doesn't entirely make sense -- it could be assuming a read-only base for the chroot, like docker or snapshot-able VM images or running the chroot in a loop-mounted ISO image or ...
– quixotic
Mar 21 '17 at 4:14
> Its unclear what you mean by "changes to the filesystem" That was to avoid docker fans to flood the topic :) What I really need is to be able to install any package, which pulls a lot of dependencies in that way it won't pollute the system, and be usable in the shell like it is installed in /usr/bin. So I would like it to use main root, but all the changes it produces, including dependencies, logs, etc. to be stored in separate directory. I want it to know nothing about root system, and the processes it's running, as it won't work smoothly.
– user4674453
Mar 21 '17 at 22:36
add a comment |
mounting the real/proc
in the chroot is pretty much exactly what the question is trying to avoid.
– quixotic
Mar 21 '17 at 4:00
@quixotic - if thats the case, the answer is "no" - unless a lot more information given as to what specific parts of /proc are needed. Rereading the question, I wonder if the understanding of filesystems is correct - as in does "changes to the filesystem must be preserved" imply access to files outside the scope of the directories under the chroot jail.
– davidgo
Mar 21 '17 at 4:06
agree that doesn't entirely make sense -- it could be assuming a read-only base for the chroot, like docker or snapshot-able VM images or running the chroot in a loop-mounted ISO image or ...
– quixotic
Mar 21 '17 at 4:14
> Its unclear what you mean by "changes to the filesystem" That was to avoid docker fans to flood the topic :) What I really need is to be able to install any package, which pulls a lot of dependencies in that way it won't pollute the system, and be usable in the shell like it is installed in /usr/bin. So I would like it to use main root, but all the changes it produces, including dependencies, logs, etc. to be stored in separate directory. I want it to know nothing about root system, and the processes it's running, as it won't work smoothly.
– user4674453
Mar 21 '17 at 22:36
mounting the real
/proc
in the chroot is pretty much exactly what the question is trying to avoid.– quixotic
Mar 21 '17 at 4:00
mounting the real
/proc
in the chroot is pretty much exactly what the question is trying to avoid.– quixotic
Mar 21 '17 at 4:00
@quixotic - if thats the case, the answer is "no" - unless a lot more information given as to what specific parts of /proc are needed. Rereading the question, I wonder if the understanding of filesystems is correct - as in does "changes to the filesystem must be preserved" imply access to files outside the scope of the directories under the chroot jail.
– davidgo
Mar 21 '17 at 4:06
@quixotic - if thats the case, the answer is "no" - unless a lot more information given as to what specific parts of /proc are needed. Rereading the question, I wonder if the understanding of filesystems is correct - as in does "changes to the filesystem must be preserved" imply access to files outside the scope of the directories under the chroot jail.
– davidgo
Mar 21 '17 at 4:06
agree that doesn't entirely make sense -- it could be assuming a read-only base for the chroot, like docker or snapshot-able VM images or running the chroot in a loop-mounted ISO image or ...
– quixotic
Mar 21 '17 at 4:14
agree that doesn't entirely make sense -- it could be assuming a read-only base for the chroot, like docker or snapshot-able VM images or running the chroot in a loop-mounted ISO image or ...
– quixotic
Mar 21 '17 at 4:14
> Its unclear what you mean by "changes to the filesystem" That was to avoid docker fans to flood the topic :) What I really need is to be able to install any package, which pulls a lot of dependencies in that way it won't pollute the system, and be usable in the shell like it is installed in /usr/bin. So I would like it to use main root, but all the changes it produces, including dependencies, logs, etc. to be stored in separate directory. I want it to know nothing about root system, and the processes it's running, as it won't work smoothly.
– user4674453
Mar 21 '17 at 22:36
> Its unclear what you mean by "changes to the filesystem" That was to avoid docker fans to flood the topic :) What I really need is to be able to install any package, which pulls a lot of dependencies in that way it won't pollute the system, and be usable in the shell like it is installed in /usr/bin. So I would like it to use main root, but all the changes it produces, including dependencies, logs, etc. to be stored in separate directory. I want it to know nothing about root system, and the processes it's running, as it won't work smoothly.
– user4674453
Mar 21 '17 at 22:36
add a comment |
up vote
0
down vote
You can accomplish this using Linux namespaces. Containers (Docker, lxc) are made out of those. man unshare
is Your friend.
Beware that attacker can easily escape chroot
if You use it improperly. Read up on this before using it. You have been warned.
add a comment |
up vote
0
down vote
You can accomplish this using Linux namespaces. Containers (Docker, lxc) are made out of those. man unshare
is Your friend.
Beware that attacker can easily escape chroot
if You use it improperly. Read up on this before using it. You have been warned.
add a comment |
up vote
0
down vote
up vote
0
down vote
You can accomplish this using Linux namespaces. Containers (Docker, lxc) are made out of those. man unshare
is Your friend.
Beware that attacker can easily escape chroot
if You use it improperly. Read up on this before using it. You have been warned.
You can accomplish this using Linux namespaces. Containers (Docker, lxc) are made out of those. man unshare
is Your friend.
Beware that attacker can easily escape chroot
if You use it improperly. Read up on this before using it. You have been warned.
answered Nov 19 at 20:51
lynx
12
12
add a comment |
add a comment |
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsuperuser.com%2fquestions%2f1190640%2fis-it-possible-to-run-a-process-in-chroot-with-virtual-proc-filesystem-under-li%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
1
Any particular reason for trying to achieve such behavior?
– ddnomad
Mar 21 '17 at 1:31
a VM or LXC container will give you a real-looking
/proc
without actually being the host's/proc
.– quixotic
Mar 21 '17 at 4:09