Mixing
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
asked Jan 27 at 11:46
throwaway12throwaway12
42
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
asked Jan 27 at 11:46
throwaway12throwaway12
42
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.
– 炸鱼薯条德里克
Jan 27 at 11:53
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
asked Jan 27 at 11:46
throwaway12throwaway12
42
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
asked Jan 27 at 11:46
throwaway12throwaway12
42
asked Jan 27 at 11:46
throwaway12throwaway12
42
asked Jan 27 at 11:46
throwaway12throwaway12
42
asked Jan 27 at 11:46
throwaway12throwaway12
42
asked Jan 27 at 11:46
throwaway12throwaway12
42
42
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.
– 炸鱼薯条德里克
Jan 27 at 11:53
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.
– 炸鱼薯条德里克
Jan 27 at 11:53
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.
– 炸鱼薯条德里克
Jan 27 at 11:53
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.
– 炸鱼薯条德里克
Jan 27 at 11:53
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.
answered Jan 27 at 11:50
KusalanandaKusalananda
137k17258426
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.
answered Jan 27 at 12:54
JdeBPJdeBP
37.5k478180
I suspect the 'xe' in the first line is a typo? (Otherwise, good answer)
– Time4Tea
Jan 27 at 13:35
No.
– JdeBP
Jan 27 at 13:39
Interesting. I've never heard that term before.
– Time4Tea
Jan 27 at 17:18
@Time4Tea and hopefully it won't be heard ever again ;-)
– Uncle Billy
Jan 27 at 22:12
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.
answered Jan 27 at 14:19
rackandbonemanrackandboneman
39915
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
Jan 27 at 15:09
In the kernels, no doubt. In all suid userspace stuff, too?
– rackandboneman
Jan 27 at 22:35
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
});
}
});
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.
answered Jan 27 at 11:50
KusalanandaKusalananda
137k17258426
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.
answered Jan 27 at 11:50
KusalanandaKusalananda
137k17258426
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.
answered Jan 27 at 11:50
KusalanandaKusalananda
137k17258426
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 Jan 27 at 11:50
KusalanandaKusalananda
137k17258426
answered Jan 27 at 11:50
KusalanandaKusalananda
137k17258426
answered Jan 27 at 11:50
KusalanandaKusalananda
137k17258426
answered Jan 27 at 11:50
KusalanandaKusalananda
137k17258426
137k17258426
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.
answered Jan 27 at 12:54
JdeBPJdeBP
37.5k478180
I suspect the 'xe' in the first line is a typo? (Otherwise, good answer)
– Time4Tea
Jan 27 at 13:35
No.
– JdeBP
Jan 27 at 13:39
Interesting. I've never heard that term before.
– Time4Tea
Jan 27 at 17:18
@Time4Tea and hopefully it won't be heard ever again ;-)
– Uncle Billy
Jan 27 at 22:12
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.
answered Jan 27 at 12:54
JdeBPJdeBP
37.5k478180
I suspect the 'xe' in the first line is a typo? (Otherwise, good answer)
– Time4Tea
Jan 27 at 13:35
No.
– JdeBP
Jan 27 at 13:39
Interesting. I've never heard that term before.
– Time4Tea
Jan 27 at 17:18
@Time4Tea and hopefully it won't be heard ever again ;-)
– Uncle Billy
Jan 27 at 22:12
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.
answered Jan 27 at 12:54
JdeBPJdeBP
37.5k478180
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 Jan 27 at 12:54
JdeBPJdeBP
37.5k478180
answered Jan 27 at 12:54
JdeBPJdeBP
37.5k478180
answered Jan 27 at 12:54
JdeBPJdeBP
37.5k478180
answered Jan 27 at 12:54
JdeBPJdeBP
37.5k478180
37.5k478180
I suspect the 'xe' in the first line is a typo? (Otherwise, good answer)
– Time4Tea
Jan 27 at 13:35
No.
– JdeBP
Jan 27 at 13:39
Interesting. I've never heard that term before.
– Time4Tea
Jan 27 at 17:18
@Time4Tea and hopefully it won't be heard ever again ;-)
– Uncle Billy
Jan 27 at 22:12
add a comment |
I suspect the 'xe' in the first line is a typo? (Otherwise, good answer)
– Time4Tea
Jan 27 at 13:35
No.
– JdeBP
Jan 27 at 13:39
Interesting. I've never heard that term before.
– Time4Tea
Jan 27 at 17:18
@Time4Tea and hopefully it won't be heard ever again ;-)
– Uncle Billy
Jan 27 at 22:12
I suspect the 'xe' in the first line is a typo? (Otherwise, good answer)
– Time4Tea
Jan 27 at 13:35
I suspect the 'xe' in the first line is a typo? (Otherwise, good answer)
– Time4Tea
Jan 27 at 13:35
No.
– JdeBP
Jan 27 at 13:39
No.
– JdeBP
Jan 27 at 13:39
Interesting. I've never heard that term before.
– Time4Tea
Jan 27 at 17:18
Interesting. I've never heard that term before.
– Time4Tea
Jan 27 at 17:18
@Time4Tea and hopefully it won't be heard ever again ;-)
– Uncle Billy
Jan 27 at 22:12
@Time4Tea and hopefully it won't be heard ever again ;-)
– Uncle Billy
Jan 27 at 22:12
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.
answered Jan 27 at 14:19
rackandbonemanrackandboneman
39915
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
Jan 27 at 15:09
In the kernels, no doubt. In all suid userspace stuff, too?
– rackandboneman
Jan 27 at 22:35
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.
answered Jan 27 at 14:19
rackandbonemanrackandboneman
39915
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
Jan 27 at 15:09
In the kernels, no doubt. In all suid userspace stuff, too?
– rackandboneman
Jan 27 at 22:35
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.
answered Jan 27 at 14:19
rackandbonemanrackandboneman
39915
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 Jan 27 at 14:19
rackandbonemanrackandboneman
39915
answered Jan 27 at 14:19
rackandbonemanrackandboneman
39915
answered Jan 27 at 14:19
rackandbonemanrackandboneman
39915
answered Jan 27 at 14:19
rackandbonemanrackandboneman
39915
39915
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
Jan 27 at 15:09
In the kernels, no doubt. In all suid userspace stuff, too?
– rackandboneman
Jan 27 at 22:35
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
Jan 27 at 15:09
In the kernels, no doubt. In all suid userspace stuff, too?
– rackandboneman
Jan 27 at 22:35
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
Jan 27 at 15:09
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
Jan 27 at 15:09
In the kernels, no doubt. In all suid userspace stuff, too?
– rackandboneman
Jan 27 at 22:35
In the kernels, no doubt. In all suid userspace stuff, too?
– rackandboneman
Jan 27 at 22:35
add a comment |
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.
– 炸鱼薯条德里克
Jan 27 at 11:53