4

Are per-file and directory access permissions for an user or a group stored as part of the NTFS structures on-disk? Or are they recorded in the registry database for an installed Windows OS, or elsewhere yet?

In practice, assuming several NT-class OSes accessing common HD volumes, can I safely make mods/repairs to the access permissions on one without affecting the other windowses? In other words, will any file system object's permissions that are set/modified while running OS 1 affect the permissions applicable to the same object, as seen while running OS 2 at a later time?

The question is limited to Windows NT type operating systems only.

Anders
  • 64,406
  • 24
  • 178
  • 215
NimbUs
  • 101
  • 1
  • 5
  • 1
    They're stored as filesystem metadata, not in the registry. I'll write up an answer referencing the on-disk format tomorrow if there are no answers by then. – forest Feb 10 '18 at 14:32
  • 2
    Forest is correct, they are part of the NTFS metadata for each file. – Polynomial Feb 10 '18 at 15:02
  • Thanks Forest & Polynomial, this answers my query in part. Thus in the situation when we want to be able to access objects on one NTFS volume from two distinct NT OSes, we have to define cumulative permissions in order to satisfy both of them, right ? Can it be done in a peaceful manner, without conflicts, w/o having to reassign permissions each time one boots another OS ? Not just user permissions, object ownership too. Are such scenarios "unsupported" or is some guidance available ? – NimbUs Feb 10 '18 at 15:21

3 Answers3

2

On NTFS volumes, various access permissions applicable to securable file system objects such as files and folders are stored as metadata (Access control lists, ACLs) that are part of the file system. During normal operation, Microsoft Windows NT and successor OSes enforce said permissions strictly.

If a given NTFS volume is to be used alternatively in 2 or more different installed OSes, one must therefore be very careful not to mess with or destroy existing permissions, set in another OS and which may be necessary for the proper operation of it - especially permissions on system folders and files.

In the particular instance which affected an old windows 2000 Pro, I had carelessly messed with permissions for its whole System32 folder hierarchy, using a "convenient" point and click so-called "unlocker assistant" while running Windows 7. Repaired the mess, while running Windows 2000, by reapplying the "secedit" to (an extract from) the relevant default security template (found at %SystemRoot%\security\templates).

NimbUs
  • 101
  • 1
  • 5
0

The filesystem uses inodes (unix/linux systems) or File ID's (Windows systems) to describe objects stored on disk. Each one has properties such as create date, access date, permissions including read, write, execute, archive and user group ownership information. NTFS, like many other file systems such as ZFS, EXT(2,3,4), reiserfs, btrfs etc use this metadata to provide to the OS, this in turn determines access.

Those attributes are stored in the MFT which is a relational database containing the inode (or as pointed out the File ID), see here

jas-
  • 931
  • 5
  • 9
  • 1
    Does NTFS actually use inodes? I thought it used an entirely different concept. I think the closest NTFS has is "File IDs", which are roughly similar to the inode number, but I don't think the technique of storing metadata in a specific block that then links to a linked list (or similar construct) is used in NTFS. – forest Feb 10 '18 at 23:46
  • While the naming convention may be different it is still an integer representation of a file and it's associated attributes – jas- Feb 12 '18 at 05:44
  • Any data structure can be represented as an integer. That doesn't make it an inode (which has very specific properties. It's not just any old number that represents a file). – forest Feb 24 '18 at 03:04
  • Indeed, however objects; files, folders etc are all represented on disk as an integer which has properties associated with them. – jas- Feb 24 '18 at 03:24
0

In windows security descriptors are stored in a file $Secure located inside every drive. Every file in that drive is mapped to one of the security descriptor present within $Secure

Kamaal
  • 1