This tip describes some basics of the Windows 2000 file system security apparatus. It is extracted from InformIT. The author also wrote Inside Windows 2000 Server
Requires Free Membership to View
When you register, you’ll also receive targeted alerts from my team of editorial writers and independent industry experts with the latest news, tips, and advice to help you do your job more efficiently and effectively. Our goal is to keep you informed on the hottest topics and biggest challenges faced by IT professionals today working with desktop management and security technologies.
Cathleen A. Gagne, Senior Editorial Director
, from which this information originates.
If systems management were a three-ring circus -- and when isn't it -- the acts attracting the most attention would be security, reliability and performance. Ideally, each act would get equal attention, but considering that the audience consists mostly of irate users, harried managers and demanding customers, the focus usually goes to reliability and performance. Poor old security is left in the back ring with the toothless tiger and the clown with a bad back. At least, that is, until an unstable employee erases the last three years of accounts receivables files and flees to Macedonia. Then security is ushered into the center ring with a fanfare.
This [tip] covers a functional overview of NTFS File and Directory permissions, including access control lists, standard permissions and permission inheritance. Every process spawned by the user runs in the user's security context, meaning that the process carries a copy of the user's access token. When the process accesses a security object, such as a file, folder, registry key, or directory object, it presents the user's access token.
The Security Reference Monitor (SRM) compares the contents of the user's access token to the contents of an Access Control List (ACL) inside the security descriptor attached to the object. The ACL has one or more Access Control Entries (ACEs) that identify security principals who are or are not permitted to access the object. Each ACE contains a set of permissions that defines what can or cannot be done to the object by the security principal.
All processes run in a security context. Most background services run in the security context of the local system. You can determine the security context for a service by opening the services console, right-clicking one of the running services and selecting properties from the fly-out menu. With the properties window open, select the log on tab to see the account used by the service.
You may encounter services that run in a security context other than local system. Examples of these include backup programs and virus scanners. When these applications are installed, they create special user accounts. Those accounts provide the security context for the application. When you check the service properties for the application, you'll see the name of a user account rather than local system. If the user account were deleted, or if the password were to change without notifying the application, then the application would cease to function.
Every process spawned by the user runs in the user's security context, meaning that the process carries a copy of the user's access token. When the process accesses a security object, such as a file, folder, registry key, or directory object, it presents the user's access token. To read this entire tip, click over to InformIT. You have to register, but registration is free.
This was first published in May 2001