What happens if one tries to access a root directory on a hard drive from another computer?
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
New contributor
add a comment |
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
New contributor
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
add a comment |
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
New contributor
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
filesystems root non-root-user
New contributor
New contributor
New contributor
asked yesterday
throwaway12throwaway12
42
42
New contributor
New contributor
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
add a comment |
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
add a comment |
3 Answers
3
active
oldest
votes
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.
add a comment |
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.
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
add a comment |
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.
Thesuser()
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 withpriv_check()
checks.
– JdeBP
yesterday
In the kernels, no doubt. In all suid userspace stuff, too?
– rackandboneman
yesterday
add a comment |
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.
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%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
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.
add a comment |
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.
add a comment |
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.
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.
answered yesterday
KusalanandaKusalananda
127k16239393
127k16239393
add a comment |
add a comment |
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.
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
add a comment |
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.
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
add a comment |
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.
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.
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
add a comment |
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
add a comment |
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.
Thesuser()
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 withpriv_check()
checks.
– JdeBP
yesterday
In the kernels, no doubt. In all suid userspace stuff, too?
– rackandboneman
yesterday
add a comment |
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.
Thesuser()
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 withpriv_check()
checks.
– JdeBP
yesterday
In the kernels, no doubt. In all suid userspace stuff, too?
– rackandboneman
yesterday
add a comment |
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.
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.
answered yesterday
rackandbonemanrackandboneman
38915
38915
Thesuser()
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 withpriv_check()
checks.
– JdeBP
yesterday
In the kernels, no doubt. In all suid userspace stuff, too?
– rackandboneman
yesterday
add a comment |
Thesuser()
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 withpriv_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
add a comment |
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.
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.
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%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
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
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