What happens if one tries to access a root directory on a hard drive from another computer?












0















Lets say you have a directory which is only accessible with root privileges. What happens if someone takes the physical drive out of the computer and mounts the filesystem (maybe even using another operating system)? Will he be able to read directory and its contents?










share|improve this question







New contributor




throwaway12 is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.





















  • ACL is only meaningful for a running linux kernel. Depending on the other OS, you may or may not be able to access the contents since that OS might still respect the ACL and reject your access. Or might not.

    – 炸鱼薯条德里克
    yesterday
















0















Lets say you have a directory which is only accessible with root privileges. What happens if someone takes the physical drive out of the computer and mounts the filesystem (maybe even using another operating system)? Will he be able to read directory and its contents?










share|improve this question







New contributor




throwaway12 is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.





















  • ACL is only meaningful for a running linux kernel. Depending on the other OS, you may or may not be able to access the contents since that OS might still respect the ACL and reject your access. Or might not.

    – 炸鱼薯条德里克
    yesterday














0












0








0








Lets say you have a directory which is only accessible with root privileges. What happens if someone takes the physical drive out of the computer and mounts the filesystem (maybe even using another operating system)? Will he be able to read directory and its contents?










share|improve this question







New contributor




throwaway12 is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.












Lets say you have a directory which is only accessible with root privileges. What happens if someone takes the physical drive out of the computer and mounts the filesystem (maybe even using another operating system)? Will he be able to read directory and its contents?







filesystems root non-root-user






share|improve this question







New contributor




throwaway12 is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.











share|improve this question







New contributor




throwaway12 is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.









share|improve this question




share|improve this question






New contributor




throwaway12 is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.









asked yesterday









throwaway12throwaway12

42




42




New contributor




throwaway12 is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.





New contributor





throwaway12 is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.






throwaway12 is a new contributor to this site. Take care in asking for clarification, commenting, and answering.
Check out our Code of Conduct.













  • ACL is only meaningful for a running linux kernel. Depending on the other OS, you may or may not be able to access the contents since that OS might still respect the ACL and reject your access. Or might not.

    – 炸鱼薯条德里克
    yesterday



















  • ACL is only meaningful for a running linux kernel. Depending on the other OS, you may or may not be able to access the contents since that OS might still respect the ACL and reject your access. Or might not.

    – 炸鱼薯条德里克
    yesterday

















ACL is only meaningful for a running linux kernel. Depending on the other OS, you may or may not be able to access the contents since that OS might still respect the ACL and reject your access. Or might not.

– 炸鱼薯条德里克
yesterday





ACL is only meaningful for a running linux kernel. Depending on the other OS, you may or may not be able to access the contents since that OS might still respect the ACL and reject your access. Or might not.

– 炸鱼薯条德里克
yesterday










3 Answers
3






active

oldest

votes


















4














A directory readable by only root on your system would be readable by root on anyone else's system too.



If the physical security of the system is compromised, only encryption would possibly protect the data.



Note that a user with physical access to a machine may also choose to boot the system into single-user mode to access files as root, without extracting the hard drive from the machine.






share|improve this answer































    1














    Yes, xe will.



    Unequivocally.



    Even noting that the question is not about Linux specifically.





    • Other operating systems need not respect the on-disc ACLs and permissions of a filesystem at all.

    • Disc access does not have to be via an operating system's own filesystem drivers and security mechanisms in the first place. The relevant filesystem format's equivalent of the mtools package is possible after all.

      Indeed, it would be a mere exercise in setting up one's own translator for the filesystem and an intermediary auth server on GNU Hurd.



    • Even other instances of the same operating system will just apply their own UIDs and GIDs to the on-disc ACLs and permissions. And of course UID 0 is the same across all such operating systems.


    The third point is one of the things that is famously different about the Windows NT SID model to the Unix ID model. Most SIDs, even those of local administrators, incorporate a machine-specific part. So a transplanted disc volume containing ACLs for local administrator of machine A (S-1-5-21-machineA-500) will not permit access (without taking ownership) to local administrator of machine B (S-1-5-21-machineB-500), because they are different IDs and the on-disc IDs in the ACEs are globally unique. In the Unix model, UID 0 is the same number on disc on all machines and it is only locally unique to an individual machine.



    (Interestingly, the SID of the TrustedInstaller user who has full access to many of the operating system files on a modern Windows NT system, is globally unique. Also interestingly, domain SIDs work by having a single shared machine-specific part.)



    So you can move discs around between instances of the same operating system in the Windows NT case, and the operating system will respect the ACLs from other machines and not treat them as its own users and groups. The other two points still apply, though.



    Therefore:



    To make a volume whose contents cannot be read using the same or another operating system on other machines (or even your own), use encryption.






    share|improve this answer
























    • I suspect the 'xe' in the first line is a typo? (Otherwise, good answer)

      – Time4Tea
      yesterday











    • No.

      – JdeBP
      yesterday











    • Interesting. I've never heard that term before.

      – Time4Tea
      yesterday











    • @Time4Tea and hopefully it won't be heard ever again ;-)

      – Uncle Billy
      yesterday



















    0














    If we are assuming basic unix authorisation mechanics (without any ACL, MAC etc. extensions loaded), all privileges that a certain numeric UID has will exist on any system that filesystem is mounted on. Since the root user is practically always UID 0 (might be different in some exotic system, but they'd have to get all cases of "uid || do _privileged_stuff();" out of everything ;) ) these privileges will transfer. The situation would be even more messy if you had the same users with different UIDs across machines - unix kernels do not know or care about user names at all, to them you are a number, and it is not their business whether you are a free man. Tying user names and UIDs together is the business of the userspace software involved in logging on (getty, login, pam, etc), keeping them tied together is the business of libc and the resolver software.






    share|improve this answer
























    • The suser() function existed for many years, since at least 4.3BSD, and indeed the work to replace the cases where it was called has long since been done in many kernels. FreeBSD replaced it with priv_check() checks.

      – JdeBP
      yesterday











    • In the kernels, no doubt. In all suid userspace stuff, too?

      – rackandboneman
      yesterday











    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
    });


    }
    });






    throwaway12 is a new contributor. Be nice, and check out our Code of Conduct.










    draft saved

    draft discarded


















    StackExchange.ready(
    function () {
    StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f496996%2fwhat-happens-if-one-tries-to-access-a-root-directory-on-a-hard-drive-from-anothe%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









    4














    A directory readable by only root on your system would be readable by root on anyone else's system too.



    If the physical security of the system is compromised, only encryption would possibly protect the data.



    Note that a user with physical access to a machine may also choose to boot the system into single-user mode to access files as root, without extracting the hard drive from the machine.






    share|improve this answer




























      4














      A directory readable by only root on your system would be readable by root on anyone else's system too.



      If the physical security of the system is compromised, only encryption would possibly protect the data.



      Note that a user with physical access to a machine may also choose to boot the system into single-user mode to access files as root, without extracting the hard drive from the machine.






      share|improve this answer


























        4












        4








        4







        A directory readable by only root on your system would be readable by root on anyone else's system too.



        If the physical security of the system is compromised, only encryption would possibly protect the data.



        Note that a user with physical access to a machine may also choose to boot the system into single-user mode to access files as root, without extracting the hard drive from the machine.






        share|improve this answer













        A directory readable by only root on your system would be readable by root on anyone else's system too.



        If the physical security of the system is compromised, only encryption would possibly protect the data.



        Note that a user with physical access to a machine may also choose to boot the system into single-user mode to access files as root, without extracting the hard drive from the machine.







        share|improve this answer












        share|improve this answer



        share|improve this answer










        answered yesterday









        KusalanandaKusalananda

        127k16239393




        127k16239393

























            1














            Yes, xe will.



            Unequivocally.



            Even noting that the question is not about Linux specifically.





            • Other operating systems need not respect the on-disc ACLs and permissions of a filesystem at all.

            • Disc access does not have to be via an operating system's own filesystem drivers and security mechanisms in the first place. The relevant filesystem format's equivalent of the mtools package is possible after all.

              Indeed, it would be a mere exercise in setting up one's own translator for the filesystem and an intermediary auth server on GNU Hurd.



            • Even other instances of the same operating system will just apply their own UIDs and GIDs to the on-disc ACLs and permissions. And of course UID 0 is the same across all such operating systems.


            The third point is one of the things that is famously different about the Windows NT SID model to the Unix ID model. Most SIDs, even those of local administrators, incorporate a machine-specific part. So a transplanted disc volume containing ACLs for local administrator of machine A (S-1-5-21-machineA-500) will not permit access (without taking ownership) to local administrator of machine B (S-1-5-21-machineB-500), because they are different IDs and the on-disc IDs in the ACEs are globally unique. In the Unix model, UID 0 is the same number on disc on all machines and it is only locally unique to an individual machine.



            (Interestingly, the SID of the TrustedInstaller user who has full access to many of the operating system files on a modern Windows NT system, is globally unique. Also interestingly, domain SIDs work by having a single shared machine-specific part.)



            So you can move discs around between instances of the same operating system in the Windows NT case, and the operating system will respect the ACLs from other machines and not treat them as its own users and groups. The other two points still apply, though.



            Therefore:



            To make a volume whose contents cannot be read using the same or another operating system on other machines (or even your own), use encryption.






            share|improve this answer
























            • I suspect the 'xe' in the first line is a typo? (Otherwise, good answer)

              – Time4Tea
              yesterday











            • No.

              – JdeBP
              yesterday











            • Interesting. I've never heard that term before.

              – Time4Tea
              yesterday











            • @Time4Tea and hopefully it won't be heard ever again ;-)

              – Uncle Billy
              yesterday
















            1














            Yes, xe will.



            Unequivocally.



            Even noting that the question is not about Linux specifically.





            • Other operating systems need not respect the on-disc ACLs and permissions of a filesystem at all.

            • Disc access does not have to be via an operating system's own filesystem drivers and security mechanisms in the first place. The relevant filesystem format's equivalent of the mtools package is possible after all.

              Indeed, it would be a mere exercise in setting up one's own translator for the filesystem and an intermediary auth server on GNU Hurd.



            • Even other instances of the same operating system will just apply their own UIDs and GIDs to the on-disc ACLs and permissions. And of course UID 0 is the same across all such operating systems.


            The third point is one of the things that is famously different about the Windows NT SID model to the Unix ID model. Most SIDs, even those of local administrators, incorporate a machine-specific part. So a transplanted disc volume containing ACLs for local administrator of machine A (S-1-5-21-machineA-500) will not permit access (without taking ownership) to local administrator of machine B (S-1-5-21-machineB-500), because they are different IDs and the on-disc IDs in the ACEs are globally unique. In the Unix model, UID 0 is the same number on disc on all machines and it is only locally unique to an individual machine.



            (Interestingly, the SID of the TrustedInstaller user who has full access to many of the operating system files on a modern Windows NT system, is globally unique. Also interestingly, domain SIDs work by having a single shared machine-specific part.)



            So you can move discs around between instances of the same operating system in the Windows NT case, and the operating system will respect the ACLs from other machines and not treat them as its own users and groups. The other two points still apply, though.



            Therefore:



            To make a volume whose contents cannot be read using the same or another operating system on other machines (or even your own), use encryption.






            share|improve this answer
























            • I suspect the 'xe' in the first line is a typo? (Otherwise, good answer)

              – Time4Tea
              yesterday











            • No.

              – JdeBP
              yesterday











            • Interesting. I've never heard that term before.

              – Time4Tea
              yesterday











            • @Time4Tea and hopefully it won't be heard ever again ;-)

              – Uncle Billy
              yesterday














            1












            1








            1







            Yes, xe will.



            Unequivocally.



            Even noting that the question is not about Linux specifically.





            • Other operating systems need not respect the on-disc ACLs and permissions of a filesystem at all.

            • Disc access does not have to be via an operating system's own filesystem drivers and security mechanisms in the first place. The relevant filesystem format's equivalent of the mtools package is possible after all.

              Indeed, it would be a mere exercise in setting up one's own translator for the filesystem and an intermediary auth server on GNU Hurd.



            • Even other instances of the same operating system will just apply their own UIDs and GIDs to the on-disc ACLs and permissions. And of course UID 0 is the same across all such operating systems.


            The third point is one of the things that is famously different about the Windows NT SID model to the Unix ID model. Most SIDs, even those of local administrators, incorporate a machine-specific part. So a transplanted disc volume containing ACLs for local administrator of machine A (S-1-5-21-machineA-500) will not permit access (without taking ownership) to local administrator of machine B (S-1-5-21-machineB-500), because they are different IDs and the on-disc IDs in the ACEs are globally unique. In the Unix model, UID 0 is the same number on disc on all machines and it is only locally unique to an individual machine.



            (Interestingly, the SID of the TrustedInstaller user who has full access to many of the operating system files on a modern Windows NT system, is globally unique. Also interestingly, domain SIDs work by having a single shared machine-specific part.)



            So you can move discs around between instances of the same operating system in the Windows NT case, and the operating system will respect the ACLs from other machines and not treat them as its own users and groups. The other two points still apply, though.



            Therefore:



            To make a volume whose contents cannot be read using the same or another operating system on other machines (or even your own), use encryption.






            share|improve this answer













            Yes, xe will.



            Unequivocally.



            Even noting that the question is not about Linux specifically.





            • Other operating systems need not respect the on-disc ACLs and permissions of a filesystem at all.

            • Disc access does not have to be via an operating system's own filesystem drivers and security mechanisms in the first place. The relevant filesystem format's equivalent of the mtools package is possible after all.

              Indeed, it would be a mere exercise in setting up one's own translator for the filesystem and an intermediary auth server on GNU Hurd.



            • Even other instances of the same operating system will just apply their own UIDs and GIDs to the on-disc ACLs and permissions. And of course UID 0 is the same across all such operating systems.


            The third point is one of the things that is famously different about the Windows NT SID model to the Unix ID model. Most SIDs, even those of local administrators, incorporate a machine-specific part. So a transplanted disc volume containing ACLs for local administrator of machine A (S-1-5-21-machineA-500) will not permit access (without taking ownership) to local administrator of machine B (S-1-5-21-machineB-500), because they are different IDs and the on-disc IDs in the ACEs are globally unique. In the Unix model, UID 0 is the same number on disc on all machines and it is only locally unique to an individual machine.



            (Interestingly, the SID of the TrustedInstaller user who has full access to many of the operating system files on a modern Windows NT system, is globally unique. Also interestingly, domain SIDs work by having a single shared machine-specific part.)



            So you can move discs around between instances of the same operating system in the Windows NT case, and the operating system will respect the ACLs from other machines and not treat them as its own users and groups. The other two points still apply, though.



            Therefore:



            To make a volume whose contents cannot be read using the same or another operating system on other machines (or even your own), use encryption.







            share|improve this answer












            share|improve this answer



            share|improve this answer










            answered yesterday









            JdeBPJdeBP

            34.3k469162




            34.3k469162













            • I suspect the 'xe' in the first line is a typo? (Otherwise, good answer)

              – Time4Tea
              yesterday











            • No.

              – JdeBP
              yesterday











            • Interesting. I've never heard that term before.

              – Time4Tea
              yesterday











            • @Time4Tea and hopefully it won't be heard ever again ;-)

              – Uncle Billy
              yesterday



















            • I suspect the 'xe' in the first line is a typo? (Otherwise, good answer)

              – Time4Tea
              yesterday











            • No.

              – JdeBP
              yesterday











            • Interesting. I've never heard that term before.

              – Time4Tea
              yesterday











            • @Time4Tea and hopefully it won't be heard ever again ;-)

              – Uncle Billy
              yesterday

















            I suspect the 'xe' in the first line is a typo? (Otherwise, good answer)

            – Time4Tea
            yesterday





            I suspect the 'xe' in the first line is a typo? (Otherwise, good answer)

            – Time4Tea
            yesterday













            No.

            – JdeBP
            yesterday





            No.

            – JdeBP
            yesterday













            Interesting. I've never heard that term before.

            – Time4Tea
            yesterday





            Interesting. I've never heard that term before.

            – Time4Tea
            yesterday













            @Time4Tea and hopefully it won't be heard ever again ;-)

            – Uncle Billy
            yesterday





            @Time4Tea and hopefully it won't be heard ever again ;-)

            – Uncle Billy
            yesterday











            0














            If we are assuming basic unix authorisation mechanics (without any ACL, MAC etc. extensions loaded), all privileges that a certain numeric UID has will exist on any system that filesystem is mounted on. Since the root user is practically always UID 0 (might be different in some exotic system, but they'd have to get all cases of "uid || do _privileged_stuff();" out of everything ;) ) these privileges will transfer. The situation would be even more messy if you had the same users with different UIDs across machines - unix kernels do not know or care about user names at all, to them you are a number, and it is not their business whether you are a free man. Tying user names and UIDs together is the business of the userspace software involved in logging on (getty, login, pam, etc), keeping them tied together is the business of libc and the resolver software.






            share|improve this answer
























            • The suser() function existed for many years, since at least 4.3BSD, and indeed the work to replace the cases where it was called has long since been done in many kernels. FreeBSD replaced it with priv_check() checks.

              – JdeBP
              yesterday











            • In the kernels, no doubt. In all suid userspace stuff, too?

              – rackandboneman
              yesterday
















            0














            If we are assuming basic unix authorisation mechanics (without any ACL, MAC etc. extensions loaded), all privileges that a certain numeric UID has will exist on any system that filesystem is mounted on. Since the root user is practically always UID 0 (might be different in some exotic system, but they'd have to get all cases of "uid || do _privileged_stuff();" out of everything ;) ) these privileges will transfer. The situation would be even more messy if you had the same users with different UIDs across machines - unix kernels do not know or care about user names at all, to them you are a number, and it is not their business whether you are a free man. Tying user names and UIDs together is the business of the userspace software involved in logging on (getty, login, pam, etc), keeping them tied together is the business of libc and the resolver software.






            share|improve this answer
























            • The suser() function existed for many years, since at least 4.3BSD, and indeed the work to replace the cases where it was called has long since been done in many kernels. FreeBSD replaced it with priv_check() checks.

              – JdeBP
              yesterday











            • In the kernels, no doubt. In all suid userspace stuff, too?

              – rackandboneman
              yesterday














            0












            0








            0







            If we are assuming basic unix authorisation mechanics (without any ACL, MAC etc. extensions loaded), all privileges that a certain numeric UID has will exist on any system that filesystem is mounted on. Since the root user is practically always UID 0 (might be different in some exotic system, but they'd have to get all cases of "uid || do _privileged_stuff();" out of everything ;) ) these privileges will transfer. The situation would be even more messy if you had the same users with different UIDs across machines - unix kernels do not know or care about user names at all, to them you are a number, and it is not their business whether you are a free man. Tying user names and UIDs together is the business of the userspace software involved in logging on (getty, login, pam, etc), keeping them tied together is the business of libc and the resolver software.






            share|improve this answer













            If we are assuming basic unix authorisation mechanics (without any ACL, MAC etc. extensions loaded), all privileges that a certain numeric UID has will exist on any system that filesystem is mounted on. Since the root user is practically always UID 0 (might be different in some exotic system, but they'd have to get all cases of "uid || do _privileged_stuff();" out of everything ;) ) these privileges will transfer. The situation would be even more messy if you had the same users with different UIDs across machines - unix kernels do not know or care about user names at all, to them you are a number, and it is not their business whether you are a free man. Tying user names and UIDs together is the business of the userspace software involved in logging on (getty, login, pam, etc), keeping them tied together is the business of libc and the resolver software.







            share|improve this answer












            share|improve this answer



            share|improve this answer










            answered yesterday









            rackandbonemanrackandboneman

            38915




            38915













            • The suser() function existed for many years, since at least 4.3BSD, and indeed the work to replace the cases where it was called has long since been done in many kernels. FreeBSD replaced it with priv_check() checks.

              – JdeBP
              yesterday











            • In the kernels, no doubt. In all suid userspace stuff, too?

              – rackandboneman
              yesterday



















            • The suser() function existed for many years, since at least 4.3BSD, and indeed the work to replace the cases where it was called has long since been done in many kernels. FreeBSD replaced it with priv_check() checks.

              – JdeBP
              yesterday











            • In the kernels, no doubt. In all suid userspace stuff, too?

              – rackandboneman
              yesterday

















            The suser() function existed for many years, since at least 4.3BSD, and indeed the work to replace the cases where it was called has long since been done in many kernels. FreeBSD replaced it with priv_check() checks.

            – JdeBP
            yesterday





            The suser() function existed for many years, since at least 4.3BSD, and indeed the work to replace the cases where it was called has long since been done in many kernels. FreeBSD replaced it with priv_check() checks.

            – JdeBP
            yesterday













            In the kernels, no doubt. In all suid userspace stuff, too?

            – rackandboneman
            yesterday





            In the kernels, no doubt. In all suid userspace stuff, too?

            – rackandboneman
            yesterday










            throwaway12 is a new contributor. Be nice, and check out our Code of Conduct.










            draft saved

            draft discarded


















            throwaway12 is a new contributor. Be nice, and check out our Code of Conduct.













            throwaway12 is a new contributor. Be nice, and check out our Code of Conduct.












            throwaway12 is a new contributor. Be nice, and check out our Code of Conduct.
















            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.




            draft saved


            draft discarded














            StackExchange.ready(
            function () {
            StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2funix.stackexchange.com%2fquestions%2f496996%2fwhat-happens-if-one-tries-to-access-a-root-directory-on-a-hard-drive-from-anothe%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

            "Incorrect syntax near the keyword 'ON'. (on update cascade, on delete cascade,)

            Alcedinidae

            RAC Tourist Trophy