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?

  • 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 '19 at 11:53

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.


Yes, xe will.


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.


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 Jan 27 '19 at 13:35
  • No. – JdeBP Jan 27 '19 at 13:39
  • Interesting. I've never heard that term before. – Time4Tea Jan 27 '19 at 17:18
  • @Time4Tea and hopefully it won't be heard ever again ;-) – Uncle Billy Jan 27 '19 at 22:12

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.

  • 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 '19 at 15:09
  • In the kernels, no doubt. In all suid userspace stuff, too? – rackandboneman Jan 27 '19 at 22:35

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.