How do I tell I'm running in a chroot?












43














I have a unix installation that's supposed to be usable both as a chroot and as a standalone system. If it's running as a chroot, I don't want to run any service (cron, inetd, and so on), because they would conflict with the host system or be redundant.



How do I write a shell script that behaves differently depending on whether it's running in a chroot? My immediate need is a modern Linux system, with /proc mounted in the chroot, and the script is running as root, but more portable answers are welcome as well. (See How do I tell I'm running in a chroot if /proc is not mounted? for the case of Linux without /proc.)



More generally, suggestions that work for other containment methods would be interesting. The practical question is, is this system supposed to be running any services? (The answer being no in a chroot, and yes in a full-fledged virtual machines; I don't know about intermediate cases such as jails or containers.)










share|improve this question





























    43














    I have a unix installation that's supposed to be usable both as a chroot and as a standalone system. If it's running as a chroot, I don't want to run any service (cron, inetd, and so on), because they would conflict with the host system or be redundant.



    How do I write a shell script that behaves differently depending on whether it's running in a chroot? My immediate need is a modern Linux system, with /proc mounted in the chroot, and the script is running as root, but more portable answers are welcome as well. (See How do I tell I'm running in a chroot if /proc is not mounted? for the case of Linux without /proc.)



    More generally, suggestions that work for other containment methods would be interesting. The practical question is, is this system supposed to be running any services? (The answer being no in a chroot, and yes in a full-fledged virtual machines; I don't know about intermediate cases such as jails or containers.)










    share|improve this question



























      43












      43








      43


      25





      I have a unix installation that's supposed to be usable both as a chroot and as a standalone system. If it's running as a chroot, I don't want to run any service (cron, inetd, and so on), because they would conflict with the host system or be redundant.



      How do I write a shell script that behaves differently depending on whether it's running in a chroot? My immediate need is a modern Linux system, with /proc mounted in the chroot, and the script is running as root, but more portable answers are welcome as well. (See How do I tell I'm running in a chroot if /proc is not mounted? for the case of Linux without /proc.)



      More generally, suggestions that work for other containment methods would be interesting. The practical question is, is this system supposed to be running any services? (The answer being no in a chroot, and yes in a full-fledged virtual machines; I don't know about intermediate cases such as jails or containers.)










      share|improve this question















      I have a unix installation that's supposed to be usable both as a chroot and as a standalone system. If it's running as a chroot, I don't want to run any service (cron, inetd, and so on), because they would conflict with the host system or be redundant.



      How do I write a shell script that behaves differently depending on whether it's running in a chroot? My immediate need is a modern Linux system, with /proc mounted in the chroot, and the script is running as root, but more portable answers are welcome as well. (See How do I tell I'm running in a chroot if /proc is not mounted? for the case of Linux without /proc.)



      More generally, suggestions that work for other containment methods would be interesting. The practical question is, is this system supposed to be running any services? (The answer being no in a chroot, and yes in a full-fledged virtual machines; I don't know about intermediate cases such as jails or containers.)







      chroot






      share|improve this question















      share|improve this question













      share|improve this question




      share|improve this question








      edited Apr 13 '17 at 12:37









      Community

      1




      1










      asked Jun 3 '11 at 16:55









      Gilles

      528k12810581583




      528k12810581583






















          3 Answers
          3






          active

          oldest

          votes


















          40














          What I've done here is to test whether the root of the init process (PID 1) is the same as the root of the current process. Although /proc/1/root is always a link to / (unless init itself is chrooted, but that's not a case I care about), following it leads to the “master” root directory. This technique is used in a few maintenance scripts in Debian, for example to skip starting udev after installation in a chroot.



          if [ "$(stat -c %d:%i /)" != "$(stat -c %d:%i /proc/1/root/.)" ]; then
          echo "We are chrooted!"
          else
          echo "Business as usual"
          fi


          (By the way, this is yet another example of why chroot is useless for security if the chrooted process has root access. Non-root processes can't read /proc/1/root, but they can follow /proc/1234/root if there is a running process with PID 1234 running as the same user.)



          If you do not have root permissions, you can look at /proc/1/mountinfo and /proc/$$/mountinfo (briefly documented in filesystems/proc.txt in the Linux kernel documentation). This file is world-readable and contains a lot of information about each mount point in the process's view of the filesystem. The paths in that file are restricted by the chroot affecting the reader process, if any. If the process reading /proc/1/mountinfo is chrooted into a filesystem that's different from the global root (assuming pid 1's root is the global root), then no entry for / appears in /proc/1/mountinfo. If the process reading /proc/1/mountinfo is chrooted to a directory on the global root filesystem, then an entry for / appears in /proc/1/mountinfo, but with a different mount id. Incidentally, the root field ($4) indicates where the chroot is in its master filesystem.



          [ "$(awk '$5=="/" {print $1}' </proc/1/mountinfo)" != "$(awk '$5=="/" {print $1}' </proc/$$/mountinfo)" ]


          This is a pure Linux solution. It may be generalizable to other Unix variants with a sufficiently similar /proc (Solaris has a similar /proc/1/root, I think, but not mountinfo).






          share|improve this answer



















          • 1




            This won't work in OpenBSD because it has random PIDs; the root process is basically never PID 1. Now you know why!
            – Adam Katz
            Jan 16 '15 at 5:59










          • @AdamKatz "... with a couple of obvious exceptions, e.g., init(8)." So which is it?
            – muru
            Jan 16 '15 at 9:40










          • @muru: aw, shucks. You've shot me down. I'm not sure why init(8) would absolutely need to have the #1 slot unless there's some kind of hard-coded nature that requires it (in which I'd still be unsure as to why). Of course, the BSDs have much more advanced jails than just chroot, so I'm not even sure how problematic this is.
            – Adam Katz
            Jan 16 '15 at 10:02






          • 3




            @AdamKatz It's the opposite: pid 1 has a special role (it must reap zombies, and it is immune to SIGKILL). The init program is an implementation of that role. The reason my answer doesn't work in OpenBSD has nothing to do with this: it's because OpenBSD doesn't have anything like Solaris/Linux's /proc. My answer wasn't meant to address anything but Linux anyway.
            – Gilles
            Jan 16 '15 at 11:40












          • @Gilles I figured OpenBSD would have this defeated in some manner or other. Still, I'm surprised that all of those special role items aren't capable of being applied to an arbitrary PID (without consequences), which is what I meant in my italicized "why" earlier.
            – Adam Katz
            Jan 16 '15 at 17:11



















          20














          As mentioned in Portable way to find inode number and Detecting a chroot jail from within, you can check whether the inode number of / is 2:



          $ ls -di /
          2 /


          An inode number that's different from 2 indicates that the apparent root is not the actual root of a filesystem. This will not detect chroots that happen to be rooted on a mount point, or on operating systems with random root inode numbers.






          share|improve this answer























          • On what filesystems does this heuristic work?
            – Gilles
            Nov 9 '11 at 11:36










          • Tested on ext3 and hfs.
            – l0b0
            Nov 9 '11 at 11:52










          • So I was fooling around, and I think I've found a more reliable method that doesn't require root permissions (Linux only). I'm still open to counter-examples or more portable methods.
            – Gilles
            Nov 9 '11 at 19:15






          • 6




            This is true for ext[234], but not of all filesystems. It also only tests that your root is the root of the filesystem, which may not be mounted as the real root. In other words, if you mount another partition in /jail and chroot /jail, then it will look like the real root to this test.
            – psusi
            Nov 9 '11 at 19:26






          • 1




            @AdamKatz Apparently not. Tested in openbsd 6.0-stable, the inode number is still 2 for the actual root path while it's a random number for the chroot.
            – Dmitri DB
            Sep 16 '16 at 3:11



















          3














          While clearly not as portable as many other options listed here, if you're on a Debian-based system, try ischroot.



          See: https://manpages.debian.org/jessie/debianutils/ischroot.1.en.html



          To get the status in the console directly, using ischroot:



          ischroot;echo $?



          Exit codes:



          0 if currently running in a chroot
          1 if currently not running in a chroot
          2 if the detection is not possible (On GNU/Linux this happens if the script is not run as root).





          share|improve this answer























            Your Answer








            StackExchange.ready(function() {
            var channelOptions = {
            tags: "".split(" "),
            id: "106"
            };
            initTagRenderer("".split(" "), "".split(" "), channelOptions);

            StackExchange.using("externalEditor", function() {
            // Have to fire editor after snippets, if snippets enabled
            if (StackExchange.settings.snippets.snippetsEnabled) {
            StackExchange.using("snippets", function() {
            createEditor();
            });
            }
            else {
            createEditor();
            }
            });

            function createEditor() {
            StackExchange.prepareEditor({
            heartbeatType: 'answer',
            autoActivateHeartbeat: false,
            convertImagesToLinks: false,
            noModals: true,
            showLowRepImageUploadWarning: true,
            reputationToPostImages: null,
            bindNavPrevention: true,
            postfix: "",
            imageUploader: {
            brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
            contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
            allowUrls: true
            },
            onDemand: true,
            discardSelector: ".discard-answer"
            ,immediatelyShowMarkdownHelp:true
            });


            }
            });














            draft saved

            draft discarded


















            StackExchange.ready(
            function () {
            StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f14345%2fhow-do-i-tell-im-running-in-a-chroot%23new-answer', 'question_page');
            }
            );

            Post as a guest















            Required, but never shown

























            3 Answers
            3






            active

            oldest

            votes








            3 Answers
            3






            active

            oldest

            votes









            active

            oldest

            votes






            active

            oldest

            votes









            40














            What I've done here is to test whether the root of the init process (PID 1) is the same as the root of the current process. Although /proc/1/root is always a link to / (unless init itself is chrooted, but that's not a case I care about), following it leads to the “master” root directory. This technique is used in a few maintenance scripts in Debian, for example to skip starting udev after installation in a chroot.



            if [ "$(stat -c %d:%i /)" != "$(stat -c %d:%i /proc/1/root/.)" ]; then
            echo "We are chrooted!"
            else
            echo "Business as usual"
            fi


            (By the way, this is yet another example of why chroot is useless for security if the chrooted process has root access. Non-root processes can't read /proc/1/root, but they can follow /proc/1234/root if there is a running process with PID 1234 running as the same user.)



            If you do not have root permissions, you can look at /proc/1/mountinfo and /proc/$$/mountinfo (briefly documented in filesystems/proc.txt in the Linux kernel documentation). This file is world-readable and contains a lot of information about each mount point in the process's view of the filesystem. The paths in that file are restricted by the chroot affecting the reader process, if any. If the process reading /proc/1/mountinfo is chrooted into a filesystem that's different from the global root (assuming pid 1's root is the global root), then no entry for / appears in /proc/1/mountinfo. If the process reading /proc/1/mountinfo is chrooted to a directory on the global root filesystem, then an entry for / appears in /proc/1/mountinfo, but with a different mount id. Incidentally, the root field ($4) indicates where the chroot is in its master filesystem.



            [ "$(awk '$5=="/" {print $1}' </proc/1/mountinfo)" != "$(awk '$5=="/" {print $1}' </proc/$$/mountinfo)" ]


            This is a pure Linux solution. It may be generalizable to other Unix variants with a sufficiently similar /proc (Solaris has a similar /proc/1/root, I think, but not mountinfo).






            share|improve this answer



















            • 1




              This won't work in OpenBSD because it has random PIDs; the root process is basically never PID 1. Now you know why!
              – Adam Katz
              Jan 16 '15 at 5:59










            • @AdamKatz "... with a couple of obvious exceptions, e.g., init(8)." So which is it?
              – muru
              Jan 16 '15 at 9:40










            • @muru: aw, shucks. You've shot me down. I'm not sure why init(8) would absolutely need to have the #1 slot unless there's some kind of hard-coded nature that requires it (in which I'd still be unsure as to why). Of course, the BSDs have much more advanced jails than just chroot, so I'm not even sure how problematic this is.
              – Adam Katz
              Jan 16 '15 at 10:02






            • 3




              @AdamKatz It's the opposite: pid 1 has a special role (it must reap zombies, and it is immune to SIGKILL). The init program is an implementation of that role. The reason my answer doesn't work in OpenBSD has nothing to do with this: it's because OpenBSD doesn't have anything like Solaris/Linux's /proc. My answer wasn't meant to address anything but Linux anyway.
              – Gilles
              Jan 16 '15 at 11:40












            • @Gilles I figured OpenBSD would have this defeated in some manner or other. Still, I'm surprised that all of those special role items aren't capable of being applied to an arbitrary PID (without consequences), which is what I meant in my italicized "why" earlier.
              – Adam Katz
              Jan 16 '15 at 17:11
















            40














            What I've done here is to test whether the root of the init process (PID 1) is the same as the root of the current process. Although /proc/1/root is always a link to / (unless init itself is chrooted, but that's not a case I care about), following it leads to the “master” root directory. This technique is used in a few maintenance scripts in Debian, for example to skip starting udev after installation in a chroot.



            if [ "$(stat -c %d:%i /)" != "$(stat -c %d:%i /proc/1/root/.)" ]; then
            echo "We are chrooted!"
            else
            echo "Business as usual"
            fi


            (By the way, this is yet another example of why chroot is useless for security if the chrooted process has root access. Non-root processes can't read /proc/1/root, but they can follow /proc/1234/root if there is a running process with PID 1234 running as the same user.)



            If you do not have root permissions, you can look at /proc/1/mountinfo and /proc/$$/mountinfo (briefly documented in filesystems/proc.txt in the Linux kernel documentation). This file is world-readable and contains a lot of information about each mount point in the process's view of the filesystem. The paths in that file are restricted by the chroot affecting the reader process, if any. If the process reading /proc/1/mountinfo is chrooted into a filesystem that's different from the global root (assuming pid 1's root is the global root), then no entry for / appears in /proc/1/mountinfo. If the process reading /proc/1/mountinfo is chrooted to a directory on the global root filesystem, then an entry for / appears in /proc/1/mountinfo, but with a different mount id. Incidentally, the root field ($4) indicates where the chroot is in its master filesystem.



            [ "$(awk '$5=="/" {print $1}' </proc/1/mountinfo)" != "$(awk '$5=="/" {print $1}' </proc/$$/mountinfo)" ]


            This is a pure Linux solution. It may be generalizable to other Unix variants with a sufficiently similar /proc (Solaris has a similar /proc/1/root, I think, but not mountinfo).






            share|improve this answer



















            • 1




              This won't work in OpenBSD because it has random PIDs; the root process is basically never PID 1. Now you know why!
              – Adam Katz
              Jan 16 '15 at 5:59










            • @AdamKatz "... with a couple of obvious exceptions, e.g., init(8)." So which is it?
              – muru
              Jan 16 '15 at 9:40










            • @muru: aw, shucks. You've shot me down. I'm not sure why init(8) would absolutely need to have the #1 slot unless there's some kind of hard-coded nature that requires it (in which I'd still be unsure as to why). Of course, the BSDs have much more advanced jails than just chroot, so I'm not even sure how problematic this is.
              – Adam Katz
              Jan 16 '15 at 10:02






            • 3




              @AdamKatz It's the opposite: pid 1 has a special role (it must reap zombies, and it is immune to SIGKILL). The init program is an implementation of that role. The reason my answer doesn't work in OpenBSD has nothing to do with this: it's because OpenBSD doesn't have anything like Solaris/Linux's /proc. My answer wasn't meant to address anything but Linux anyway.
              – Gilles
              Jan 16 '15 at 11:40












            • @Gilles I figured OpenBSD would have this defeated in some manner or other. Still, I'm surprised that all of those special role items aren't capable of being applied to an arbitrary PID (without consequences), which is what I meant in my italicized "why" earlier.
              – Adam Katz
              Jan 16 '15 at 17:11














            40












            40








            40






            What I've done here is to test whether the root of the init process (PID 1) is the same as the root of the current process. Although /proc/1/root is always a link to / (unless init itself is chrooted, but that's not a case I care about), following it leads to the “master” root directory. This technique is used in a few maintenance scripts in Debian, for example to skip starting udev after installation in a chroot.



            if [ "$(stat -c %d:%i /)" != "$(stat -c %d:%i /proc/1/root/.)" ]; then
            echo "We are chrooted!"
            else
            echo "Business as usual"
            fi


            (By the way, this is yet another example of why chroot is useless for security if the chrooted process has root access. Non-root processes can't read /proc/1/root, but they can follow /proc/1234/root if there is a running process with PID 1234 running as the same user.)



            If you do not have root permissions, you can look at /proc/1/mountinfo and /proc/$$/mountinfo (briefly documented in filesystems/proc.txt in the Linux kernel documentation). This file is world-readable and contains a lot of information about each mount point in the process's view of the filesystem. The paths in that file are restricted by the chroot affecting the reader process, if any. If the process reading /proc/1/mountinfo is chrooted into a filesystem that's different from the global root (assuming pid 1's root is the global root), then no entry for / appears in /proc/1/mountinfo. If the process reading /proc/1/mountinfo is chrooted to a directory on the global root filesystem, then an entry for / appears in /proc/1/mountinfo, but with a different mount id. Incidentally, the root field ($4) indicates where the chroot is in its master filesystem.



            [ "$(awk '$5=="/" {print $1}' </proc/1/mountinfo)" != "$(awk '$5=="/" {print $1}' </proc/$$/mountinfo)" ]


            This is a pure Linux solution. It may be generalizable to other Unix variants with a sufficiently similar /proc (Solaris has a similar /proc/1/root, I think, but not mountinfo).






            share|improve this answer














            What I've done here is to test whether the root of the init process (PID 1) is the same as the root of the current process. Although /proc/1/root is always a link to / (unless init itself is chrooted, but that's not a case I care about), following it leads to the “master” root directory. This technique is used in a few maintenance scripts in Debian, for example to skip starting udev after installation in a chroot.



            if [ "$(stat -c %d:%i /)" != "$(stat -c %d:%i /proc/1/root/.)" ]; then
            echo "We are chrooted!"
            else
            echo "Business as usual"
            fi


            (By the way, this is yet another example of why chroot is useless for security if the chrooted process has root access. Non-root processes can't read /proc/1/root, but they can follow /proc/1234/root if there is a running process with PID 1234 running as the same user.)



            If you do not have root permissions, you can look at /proc/1/mountinfo and /proc/$$/mountinfo (briefly documented in filesystems/proc.txt in the Linux kernel documentation). This file is world-readable and contains a lot of information about each mount point in the process's view of the filesystem. The paths in that file are restricted by the chroot affecting the reader process, if any. If the process reading /proc/1/mountinfo is chrooted into a filesystem that's different from the global root (assuming pid 1's root is the global root), then no entry for / appears in /proc/1/mountinfo. If the process reading /proc/1/mountinfo is chrooted to a directory on the global root filesystem, then an entry for / appears in /proc/1/mountinfo, but with a different mount id. Incidentally, the root field ($4) indicates where the chroot is in its master filesystem.



            [ "$(awk '$5=="/" {print $1}' </proc/1/mountinfo)" != "$(awk '$5=="/" {print $1}' </proc/$$/mountinfo)" ]


            This is a pure Linux solution. It may be generalizable to other Unix variants with a sufficiently similar /proc (Solaris has a similar /proc/1/root, I think, but not mountinfo).







            share|improve this answer














            share|improve this answer



            share|improve this answer








            edited Jan 16 '15 at 11:43

























            answered Jun 3 '11 at 16:55









            Gilles

            528k12810581583




            528k12810581583








            • 1




              This won't work in OpenBSD because it has random PIDs; the root process is basically never PID 1. Now you know why!
              – Adam Katz
              Jan 16 '15 at 5:59










            • @AdamKatz "... with a couple of obvious exceptions, e.g., init(8)." So which is it?
              – muru
              Jan 16 '15 at 9:40










            • @muru: aw, shucks. You've shot me down. I'm not sure why init(8) would absolutely need to have the #1 slot unless there's some kind of hard-coded nature that requires it (in which I'd still be unsure as to why). Of course, the BSDs have much more advanced jails than just chroot, so I'm not even sure how problematic this is.
              – Adam Katz
              Jan 16 '15 at 10:02






            • 3




              @AdamKatz It's the opposite: pid 1 has a special role (it must reap zombies, and it is immune to SIGKILL). The init program is an implementation of that role. The reason my answer doesn't work in OpenBSD has nothing to do with this: it's because OpenBSD doesn't have anything like Solaris/Linux's /proc. My answer wasn't meant to address anything but Linux anyway.
              – Gilles
              Jan 16 '15 at 11:40












            • @Gilles I figured OpenBSD would have this defeated in some manner or other. Still, I'm surprised that all of those special role items aren't capable of being applied to an arbitrary PID (without consequences), which is what I meant in my italicized "why" earlier.
              – Adam Katz
              Jan 16 '15 at 17:11














            • 1




              This won't work in OpenBSD because it has random PIDs; the root process is basically never PID 1. Now you know why!
              – Adam Katz
              Jan 16 '15 at 5:59










            • @AdamKatz "... with a couple of obvious exceptions, e.g., init(8)." So which is it?
              – muru
              Jan 16 '15 at 9:40










            • @muru: aw, shucks. You've shot me down. I'm not sure why init(8) would absolutely need to have the #1 slot unless there's some kind of hard-coded nature that requires it (in which I'd still be unsure as to why). Of course, the BSDs have much more advanced jails than just chroot, so I'm not even sure how problematic this is.
              – Adam Katz
              Jan 16 '15 at 10:02






            • 3




              @AdamKatz It's the opposite: pid 1 has a special role (it must reap zombies, and it is immune to SIGKILL). The init program is an implementation of that role. The reason my answer doesn't work in OpenBSD has nothing to do with this: it's because OpenBSD doesn't have anything like Solaris/Linux's /proc. My answer wasn't meant to address anything but Linux anyway.
              – Gilles
              Jan 16 '15 at 11:40












            • @Gilles I figured OpenBSD would have this defeated in some manner or other. Still, I'm surprised that all of those special role items aren't capable of being applied to an arbitrary PID (without consequences), which is what I meant in my italicized "why" earlier.
              – Adam Katz
              Jan 16 '15 at 17:11








            1




            1




            This won't work in OpenBSD because it has random PIDs; the root process is basically never PID 1. Now you know why!
            – Adam Katz
            Jan 16 '15 at 5:59




            This won't work in OpenBSD because it has random PIDs; the root process is basically never PID 1. Now you know why!
            – Adam Katz
            Jan 16 '15 at 5:59












            @AdamKatz "... with a couple of obvious exceptions, e.g., init(8)." So which is it?
            – muru
            Jan 16 '15 at 9:40




            @AdamKatz "... with a couple of obvious exceptions, e.g., init(8)." So which is it?
            – muru
            Jan 16 '15 at 9:40












            @muru: aw, shucks. You've shot me down. I'm not sure why init(8) would absolutely need to have the #1 slot unless there's some kind of hard-coded nature that requires it (in which I'd still be unsure as to why). Of course, the BSDs have much more advanced jails than just chroot, so I'm not even sure how problematic this is.
            – Adam Katz
            Jan 16 '15 at 10:02




            @muru: aw, shucks. You've shot me down. I'm not sure why init(8) would absolutely need to have the #1 slot unless there's some kind of hard-coded nature that requires it (in which I'd still be unsure as to why). Of course, the BSDs have much more advanced jails than just chroot, so I'm not even sure how problematic this is.
            – Adam Katz
            Jan 16 '15 at 10:02




            3




            3




            @AdamKatz It's the opposite: pid 1 has a special role (it must reap zombies, and it is immune to SIGKILL). The init program is an implementation of that role. The reason my answer doesn't work in OpenBSD has nothing to do with this: it's because OpenBSD doesn't have anything like Solaris/Linux's /proc. My answer wasn't meant to address anything but Linux anyway.
            – Gilles
            Jan 16 '15 at 11:40






            @AdamKatz It's the opposite: pid 1 has a special role (it must reap zombies, and it is immune to SIGKILL). The init program is an implementation of that role. The reason my answer doesn't work in OpenBSD has nothing to do with this: it's because OpenBSD doesn't have anything like Solaris/Linux's /proc. My answer wasn't meant to address anything but Linux anyway.
            – Gilles
            Jan 16 '15 at 11:40














            @Gilles I figured OpenBSD would have this defeated in some manner or other. Still, I'm surprised that all of those special role items aren't capable of being applied to an arbitrary PID (without consequences), which is what I meant in my italicized "why" earlier.
            – Adam Katz
            Jan 16 '15 at 17:11




            @Gilles I figured OpenBSD would have this defeated in some manner or other. Still, I'm surprised that all of those special role items aren't capable of being applied to an arbitrary PID (without consequences), which is what I meant in my italicized "why" earlier.
            – Adam Katz
            Jan 16 '15 at 17:11













            20














            As mentioned in Portable way to find inode number and Detecting a chroot jail from within, you can check whether the inode number of / is 2:



            $ ls -di /
            2 /


            An inode number that's different from 2 indicates that the apparent root is not the actual root of a filesystem. This will not detect chroots that happen to be rooted on a mount point, or on operating systems with random root inode numbers.






            share|improve this answer























            • On what filesystems does this heuristic work?
              – Gilles
              Nov 9 '11 at 11:36










            • Tested on ext3 and hfs.
              – l0b0
              Nov 9 '11 at 11:52










            • So I was fooling around, and I think I've found a more reliable method that doesn't require root permissions (Linux only). I'm still open to counter-examples or more portable methods.
              – Gilles
              Nov 9 '11 at 19:15






            • 6




              This is true for ext[234], but not of all filesystems. It also only tests that your root is the root of the filesystem, which may not be mounted as the real root. In other words, if you mount another partition in /jail and chroot /jail, then it will look like the real root to this test.
              – psusi
              Nov 9 '11 at 19:26






            • 1




              @AdamKatz Apparently not. Tested in openbsd 6.0-stable, the inode number is still 2 for the actual root path while it's a random number for the chroot.
              – Dmitri DB
              Sep 16 '16 at 3:11
















            20














            As mentioned in Portable way to find inode number and Detecting a chroot jail from within, you can check whether the inode number of / is 2:



            $ ls -di /
            2 /


            An inode number that's different from 2 indicates that the apparent root is not the actual root of a filesystem. This will not detect chroots that happen to be rooted on a mount point, or on operating systems with random root inode numbers.






            share|improve this answer























            • On what filesystems does this heuristic work?
              – Gilles
              Nov 9 '11 at 11:36










            • Tested on ext3 and hfs.
              – l0b0
              Nov 9 '11 at 11:52










            • So I was fooling around, and I think I've found a more reliable method that doesn't require root permissions (Linux only). I'm still open to counter-examples or more portable methods.
              – Gilles
              Nov 9 '11 at 19:15






            • 6




              This is true for ext[234], but not of all filesystems. It also only tests that your root is the root of the filesystem, which may not be mounted as the real root. In other words, if you mount another partition in /jail and chroot /jail, then it will look like the real root to this test.
              – psusi
              Nov 9 '11 at 19:26






            • 1




              @AdamKatz Apparently not. Tested in openbsd 6.0-stable, the inode number is still 2 for the actual root path while it's a random number for the chroot.
              – Dmitri DB
              Sep 16 '16 at 3:11














            20












            20








            20






            As mentioned in Portable way to find inode number and Detecting a chroot jail from within, you can check whether the inode number of / is 2:



            $ ls -di /
            2 /


            An inode number that's different from 2 indicates that the apparent root is not the actual root of a filesystem. This will not detect chroots that happen to be rooted on a mount point, or on operating systems with random root inode numbers.






            share|improve this answer














            As mentioned in Portable way to find inode number and Detecting a chroot jail from within, you can check whether the inode number of / is 2:



            $ ls -di /
            2 /


            An inode number that's different from 2 indicates that the apparent root is not the actual root of a filesystem. This will not detect chroots that happen to be rooted on a mount point, or on operating systems with random root inode numbers.







            share|improve this answer














            share|improve this answer



            share|improve this answer








            edited May 23 '17 at 12:39









            Community

            1




            1










            answered Nov 9 '11 at 8:24









            l0b0

            27.6k17113242




            27.6k17113242












            • On what filesystems does this heuristic work?
              – Gilles
              Nov 9 '11 at 11:36










            • Tested on ext3 and hfs.
              – l0b0
              Nov 9 '11 at 11:52










            • So I was fooling around, and I think I've found a more reliable method that doesn't require root permissions (Linux only). I'm still open to counter-examples or more portable methods.
              – Gilles
              Nov 9 '11 at 19:15






            • 6




              This is true for ext[234], but not of all filesystems. It also only tests that your root is the root of the filesystem, which may not be mounted as the real root. In other words, if you mount another partition in /jail and chroot /jail, then it will look like the real root to this test.
              – psusi
              Nov 9 '11 at 19:26






            • 1




              @AdamKatz Apparently not. Tested in openbsd 6.0-stable, the inode number is still 2 for the actual root path while it's a random number for the chroot.
              – Dmitri DB
              Sep 16 '16 at 3:11


















            • On what filesystems does this heuristic work?
              – Gilles
              Nov 9 '11 at 11:36










            • Tested on ext3 and hfs.
              – l0b0
              Nov 9 '11 at 11:52










            • So I was fooling around, and I think I've found a more reliable method that doesn't require root permissions (Linux only). I'm still open to counter-examples or more portable methods.
              – Gilles
              Nov 9 '11 at 19:15






            • 6




              This is true for ext[234], but not of all filesystems. It also only tests that your root is the root of the filesystem, which may not be mounted as the real root. In other words, if you mount another partition in /jail and chroot /jail, then it will look like the real root to this test.
              – psusi
              Nov 9 '11 at 19:26






            • 1




              @AdamKatz Apparently not. Tested in openbsd 6.0-stable, the inode number is still 2 for the actual root path while it's a random number for the chroot.
              – Dmitri DB
              Sep 16 '16 at 3:11
















            On what filesystems does this heuristic work?
            – Gilles
            Nov 9 '11 at 11:36




            On what filesystems does this heuristic work?
            – Gilles
            Nov 9 '11 at 11:36












            Tested on ext3 and hfs.
            – l0b0
            Nov 9 '11 at 11:52




            Tested on ext3 and hfs.
            – l0b0
            Nov 9 '11 at 11:52












            So I was fooling around, and I think I've found a more reliable method that doesn't require root permissions (Linux only). I'm still open to counter-examples or more portable methods.
            – Gilles
            Nov 9 '11 at 19:15




            So I was fooling around, and I think I've found a more reliable method that doesn't require root permissions (Linux only). I'm still open to counter-examples or more portable methods.
            – Gilles
            Nov 9 '11 at 19:15




            6




            6




            This is true for ext[234], but not of all filesystems. It also only tests that your root is the root of the filesystem, which may not be mounted as the real root. In other words, if you mount another partition in /jail and chroot /jail, then it will look like the real root to this test.
            – psusi
            Nov 9 '11 at 19:26




            This is true for ext[234], but not of all filesystems. It also only tests that your root is the root of the filesystem, which may not be mounted as the real root. In other words, if you mount another partition in /jail and chroot /jail, then it will look like the real root to this test.
            – psusi
            Nov 9 '11 at 19:26




            1




            1




            @AdamKatz Apparently not. Tested in openbsd 6.0-stable, the inode number is still 2 for the actual root path while it's a random number for the chroot.
            – Dmitri DB
            Sep 16 '16 at 3:11




            @AdamKatz Apparently not. Tested in openbsd 6.0-stable, the inode number is still 2 for the actual root path while it's a random number for the chroot.
            – Dmitri DB
            Sep 16 '16 at 3:11











            3














            While clearly not as portable as many other options listed here, if you're on a Debian-based system, try ischroot.



            See: https://manpages.debian.org/jessie/debianutils/ischroot.1.en.html



            To get the status in the console directly, using ischroot:



            ischroot;echo $?



            Exit codes:



            0 if currently running in a chroot
            1 if currently not running in a chroot
            2 if the detection is not possible (On GNU/Linux this happens if the script is not run as root).





            share|improve this answer




























              3














              While clearly not as portable as many other options listed here, if you're on a Debian-based system, try ischroot.



              See: https://manpages.debian.org/jessie/debianutils/ischroot.1.en.html



              To get the status in the console directly, using ischroot:



              ischroot;echo $?



              Exit codes:



              0 if currently running in a chroot
              1 if currently not running in a chroot
              2 if the detection is not possible (On GNU/Linux this happens if the script is not run as root).





              share|improve this answer


























                3












                3








                3






                While clearly not as portable as many other options listed here, if you're on a Debian-based system, try ischroot.



                See: https://manpages.debian.org/jessie/debianutils/ischroot.1.en.html



                To get the status in the console directly, using ischroot:



                ischroot;echo $?



                Exit codes:



                0 if currently running in a chroot
                1 if currently not running in a chroot
                2 if the detection is not possible (On GNU/Linux this happens if the script is not run as root).





                share|improve this answer














                While clearly not as portable as many other options listed here, if you're on a Debian-based system, try ischroot.



                See: https://manpages.debian.org/jessie/debianutils/ischroot.1.en.html



                To get the status in the console directly, using ischroot:



                ischroot;echo $?



                Exit codes:



                0 if currently running in a chroot
                1 if currently not running in a chroot
                2 if the detection is not possible (On GNU/Linux this happens if the script is not run as root).






                share|improve this answer














                share|improve this answer



                share|improve this answer








                edited Dec 17 at 23:43









                terdon

                128k31249423




                128k31249423










                answered Jan 10 at 15:18









                thom_nic

                17810




                17810






























                    draft saved

                    draft discarded




















































                    Thanks for contributing an answer to Unix & Linux Stack Exchange!


                    • 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.




                    draft saved


                    draft discarded














                    StackExchange.ready(
                    function () {
                    StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f14345%2fhow-do-i-tell-im-running-in-a-chroot%23new-answer', 'question_page');
                    }
                    );

                    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







                    Popular posts from this blog

                    Morgemoulin

                    Scott Moir

                    Souastre