0

I have a dual boot system with both an Ubuntu Server and Windows Server installation in the same physical machine with multiple other drives (An SSD and 2 HDD's). They both mount the same drives, however as the drives were originally created on Windows and I cannot give 'EVERYONE' 'FULL-CONTROL' permissions on these drives in Windows, I want to allow the root user of my Ubuntu OS 'FULL-CONTROL' of all my NTFS (msftdata) partitions so I can create my desired permissions separately for the Linux accounts.

The same way that NT-AUTHORITY/SYSTEM always has full control over drives even if the Windows users listed in the NTFS permissions do not exist on the Windows machine, the data is recoverable by leveraging the permissions of the NT-AUTHORTY/SYSTEM account because of it's universal SID (Security Identifier) across Windows machines.

Is there a way I can give FULL-CONTROL permissions to the root user of the Linux system to all of my NTFS drives? Creating a specific account in Windows, called root, with LDAP attributes perhaps?

Please keep in mind that these OS'es cannot run simultaneously because they are on the same physical system and not virtualised in any way. I either boot Windows or boot Linux at startup.

Thanks :)

1
  • Linux doesn't care about Windows NTFS permissions and any user with appropriate permissions in Linux will be able to do everything they want to the disk. If your Windows partitions are coming up as read only in Linux then you need to disable fast startup.
    – Mokubai
    Sep 20, 2020 at 8:42

1 Answer 1

1

I want to allow the root user of my Ubuntu OS 'FULL-CONTROL' of all my NTFS (msftdata) partitions so I can create my desired permissions separately for the Linux accounts

You don't really need to do this – root on Linux always has the privilege of ignoring all local file permissions and this applies to NTFS as well. This means that root doesn't need to be listed in the ACL in order to modify it with setfacl: it can just always do that.

(Permissions and ACLs are not enforced by the filesystem itself – they are only enforced by the OS that's accessing it. The filesystem is just a data structure and cannot actively prevent the OS from outright ignoring it whenever convenient. Windows will ignore them when the caller has SeBackupPrivilege, Linux will ignore them when the caller has CAP_DAC_OVERRIDE, and so on.

For example, by default, the Linux NTFS-3G filesystem driver just doesn't enforce the NTFS ACLs entirely and gives the same access to all Linux UIDs, with synthetic file modes based purely on mount options. If you're seeing NTFS ACLs being enforced on Linux, that's something you enabled!)

That said, setfacl is definitely inconvenient to use as it's meant to control POSIX ACLs and not NT ACLs, so what you probably should do is tell NTFS-3G how to map each Linux UID to a Windows SID:

  1. Create a directory named .NTFS-3G at the root of your NTFS volume.

  2. In that directory, create a text file named UserMapping (no file extension) with contents similar to:

    <uid>:<gid>:<sid>
    1000:1000:S-1-5-21-1833069642-4243175381-1340018762-1002
    

With a mapping file, the Linux NTFS-3G driver will be able to treat your Linux account as the same entity as your Windows account, as far as file permissions are concerned. (Account names don't need to match.)

If you want to give access to accounts that only exist on Linux, you can still use chown/chmod/setfacl as root – or you can create dummy accounts on Windows, add mappings for their SIDs in the file, and be able to grant access through the Windows ACL editor.

The same way that NT-AUTHORITY/SYSTEM always has full control over drives even if the Windows users listed in the NTFS permissions do not exist on the Windows machine,

Only as long as SYSTEM itself is present in their ACLs. If you remove SYSTEM from a file's ACL, userspace processes running under this account lose access to that file just like any other account would.

the data is recoverable by leveraging the permissions of the NT-AUTHORTY/SYSTEM account because of it's universal SID (Security Identifier) across Windows machines.

Well, that's one possible method, but elevating a process to SYSTEM isn't something that's directly supported by Microsoft and ends up needing various "magic" tools. Besides, you can't actually rely on it – if someone has removed Administrators from an ACL, they can remove SYSTEM from the ACL all the same.

Instead, most "recovery" operations in Windows are based on Administrators having the OS-level privilege to change file ownership regardless of ACLs (SeTakeOwnershipPrivilege), together with the standard ACL logic which allows file owners to set new ACLs regardless of existing ACLs. The file manager will even offer to do this for you.

Alternative methods include activating SeBackupPrivilege, another OS-level privilege which completely bypasses permission checks for read operations; there is one for write operations as well. By default, all Administrators have this privilege available on demand (though unlike root on Linux, it is not active the whole time).

2
  • That was very insightful and well explained. Certainly cleared up a lot of the misconceptions I had believed while making the post. This may be worth a separate post rather than a comment, but as you pointed out and I then found out and tested. Root does have privileges over all the drives, I somehow ended up believing it didn't (maybe because of the way I mounted them previously). Anyhow, my question is, is it possible to map the uid and gid of Linux root account to the same SID as NT AUTHORITY/SYSTEM in the permissions file you are talking about without any issues? Sep 20, 2020 at 9:31
  • I don't think there would be any issues, but IMO it would be more appropriate to map it to e.g. the built-in Administrator account. Sep 20, 2020 at 9:55

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .