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
edited Mar 21 '17 at 2:09
user unknown
1,4491123
asked Mar 21 '17 at 0:30
user4674453
61
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
edited Mar 21 '17 at 2:09
user unknown
1,4491123
asked Mar 21 '17 at 0:30
user4674453
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/procwithout 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
edited Mar 21 '17 at 2:09
user unknown
1,4491123
asked Mar 21 '17 at 0:30
user4674453
61
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,4491123
asked Mar 21 '17 at 0:30
user4674453
61
edited Mar 21 '17 at 2:09
user unknown
1,4491123
asked Mar 21 '17 at 0:30
user4674453
61
edited Mar 21 '17 at 2:09
user unknown
1,4491123
edited Mar 21 '17 at 2:09
user unknown
1,4491123
edited Mar 21 '17 at 2:09
user unknown
1,4491123
1,4491123
asked Mar 21 '17 at 0:30
user4674453
61
asked Mar 21 '17 at 0:30
user4674453
61
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/procwithout 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/procwithout 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.
answered Mar 21 '17 at 3:13
davidgo
41.5k74985
mounting the real/procin 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.
answered Nov 19 at 20:51
lynx
12
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.
answered Mar 21 '17 at 3:13
davidgo
41.5k74985
mounting the real/procin 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.
answered Mar 21 '17 at 3:13
davidgo
41.5k74985
mounting the real/procin 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.
answered Mar 21 '17 at 3:13
davidgo
41.5k74985
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.5k74985
answered Mar 21 '17 at 3:13
davidgo
41.5k74985
answered Mar 21 '17 at 3:13
davidgo
41.5k74985
answered Mar 21 '17 at 3:13
davidgo
41.5k74985
41.5k74985
mounting the real/procin 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/procin 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.
answered Nov 19 at 20:51
lynx
12
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.
answered Nov 19 at 20:51
lynx
12
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.
answered Nov 19 at 20:51
lynx
12
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
answered Nov 19 at 20:51
lynx
12
answered Nov 19 at 20:51
lynx
12
answered Nov 19 at 20:51
lynx
12
12
add a comment |
add a comment |
Thanks for contributing an answer to Super User!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Some of your past answers have not been well-received, and you're in danger of being blocked from answering.
Please pay close attention to the following guidance:
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
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
/procwithout actually being the host's/proc.– quixotic
Mar 21 '17 at 4:09