XP Pro file permissions

[Andrey Tarasevich]

Hello

I'm looking for a more or less formal description of how XP Pro NTFS
file permissions work. Maybe someone can point me in the right
direction. Everything I could find on microsoft.com was rather
incomplete, couldn't give me the full picture and quickly degraded to
"How to.." level, which is not what I'm looking for.

Consider the following example. Let's say I'm logged in as an
'Administrator' - member of 'Administrators' group. I create a folder,
say, 'C:\Test'. The I explicitly specify the following permissions for
'C:\Test':

* 'Administrators' group:
Allow - Full Control

* 'Users' group:
Allow - Read & Execute
Allow - List Folder Contents
Allow - Read
Deny - Write

Permission inheritance is disabled for this folder. Now I, still logged
on as 'Administrator', enter 'C:\Test' folder and try to create another
folder inside. XP refuses with 'Access is denied' message box. Why?!!

If I remove 'Deny - Write' setting from 'Users' group, 'Administrator'
is allowed to perform modifications inside 'C:\Temp'. How come 'Deny'
setting applied to 'Users' group affects permissions of 'Administrators'
group?

Another question is related to built-in 'Everyone' group. What is the
role of this group on XP permission system? It looks like this is some
meta-group all other groups are included into. Or is it other way
around? Are there any other implicit hierarchical relationships between
other built-in XP user groups?

 

[Guest]

Since the administrator account in question is also a member of the Users group, the DENY ACL and any other ACLs will take place. DENY ACLs take precedence over Allow ACLs. So, this administrator has full control by the first ACL you created, but because of the DENY ACL for write for group "Users" also applies to Administrator, that account is denied writing. Thing to remember? DENY will overrule an allow. Use with caution

Secondly, the Everyone group is called an implied group. It does not technically exist, but the system recognizes it as a collection of any and all people. With the creation of "Authenticated Users" we now have a greater ability to give more open ACLs without giving away access to unknown users.

 

[Andrey Tarasevich]

Since the administrator account in question is also a member of the Users group, the DENY ACL and any other ACLs will take place. DENY ACLs take precedence over Allow ACLs. So, this administrator has full control by the first ACL you created, but because of the DENY ACL for write for group "Users" also applies to Administrator, that account is denied writing. Thing to remember? DENY will overrule an allow. Use with caution.

Yes, that's the conclusion I came to. But where can I see some kind of
chart or diagram of whatever that shows, what users/user groups are
implicitly included into what other user groups? For example this case
demonstrates that all members of 'Administrators' group in XP are
treated as members of 'Users' group at the same time, even though on my
machine the 'Administrator' account is not included into 'Users' group
explicitly.

This also brings the next question: how do I explicitly deny some
inherited permission to 'Users' without denying it to 'Administrators'
on some folder 'F'? The only way I see now is to stop inheriting
permissions to folder 'F' and specify all permissions explicitly. Can it
be done without breaking the inheritance?

Secondly, the Everyone group is called an implied group. It does not technically exist, but the system recognizes it as a collection of any and all people. With the creation of "Authenticated Users" we now have a greater ability to give more open ACLs without giving away access to unknown users.

Thank you for your reply.

 

[Wesley Vogel]

Andrey;

Start | Help and Support | Type: groups overview | Click arrow |
Click: Groups overview
Also look at Related Topics
===============

Here are a few interesting links.

Understanding Local Users and Groups
http://www.microsoft.com/resources/...3/standard/proddocs/en-us/lsm_local_users.asp

Security, Users, and Groups Overview
http://msdn.microsoft.com/library/d...n-us/spptsdk/html/tsovsecurityusersgroups.asp

File and Folder Permissions
http://www.microsoft.com/resources/...Windows/XP/all/reskit/en-us/prkc_fil_vtmz.asp

Over View of All Groups in Windows XP
http://www.kellys-korner-xp.com/xp_groups.htm

Introduction to User Accounts
http://windows.about.com/library/weekly/aa010325a.htm

 

[Andrey Tarasevich]

...
Start | Help and Support | Type: groups overview | Click arrow |
Click: Groups overview
Also look at Related Topics
===============

Here are a few interesting links.

Understanding Local Users and Groups
http://www.microsoft.com/resources/...3/standard/proddocs/en-us/lsm_local_users.asp

Security, Users, and Groups Overview
http://msdn.microsoft.com/library/d...n-us/spptsdk/html/tsovsecurityusersgroups.asp

File and Folder Permissions
http://www.microsoft.com/resources/...Windows/XP/all/reskit/en-us/prkc_fil_vtmz.asp

Over View of All Groups in Windows XP
http://www.kellys-korner-xp.com/xp_groups.htm

Introduction to User Accounts
http://windows.about.com/library/weekly/aa010325a.htm
...

Thank you, Wesley. But I have seen almost all of these articles. They
are pretty basic and unfortunately none of them seem to answer my
questions. That's why I ask them here. For example, I haven't seen any
of these articles mention that members of 'Administrators' group are
always considered to be members of 'Users' group (it is possible that I
missed something though).

 

[Wesley Vogel]

Andrey;

I don't believe that Administrators are part of the Users Group.
That makes no sense to me.

The Administrator and the Guest accounts are called the two built-in user
accounts.
The Groups in XP Pro are:
Administrators
Backup Operators
Power Users
Users
Guests
Replicators

[[Members of the Administrators group have the largest amount of default
permissions and the ability to change their own permissions.]]

[[Members of the Users group can perform most common tasks, such as running
applications, using local and network printers, and shutting down and
locking the workstation. Users can create local groups, but can modify only
the local groups that they created. Users cannot share directories or create
local printers.]]

The Administrators Group is higher on the food chain than the Users Group.
If the Administrators are the Ace, then the Users would be the Jack.
I don't see how, if you are part of the Administrators Group, you would
be included in a Peasant Group. )

That is pure goofiness, if you ask me.
=========

HOW TO: Take Ownership of a File or Folder in Windows XP
http://support.microsoft.com/default.aspx?scid=kb;en-us;308421

How to disable simplified sharing and set permissions on a shared folder in
Windows XP
http://support.microsoft.com/default.aspx?kbid=307874

Interaction of File and Folder Security on NTFS Volumes
http://support.microsoft.com/default.aspx?scid=kb;EN-US;161275

========

All I know for sure is; I am the sole owner/user of this machine.
I have no sharing set except my hard drive. (This has been shared for
administrative purposes. The permissions cannot be set.)
I am not on a network. I have permission to set this baby on fire
if I so desire. )

Maybe some one else will jump in and help out. ;o)

 

[Andrey Tarasevich]

...
I don't believe that Administrators are part of the Users Group.
That makes no sense to me.
...

Nevertheless, this turns out to be the case. More precisely, a locally
logged-in Administrator automatically becomes member of Users group. If
you take a look at your Users group, you'll see that it contains another
system group - 'NT AUTHORITY/INTERACTIVE'. Everybody who logs-in locally
automatically becomes a member of 'NT AUTHORITY/INTERACTIVE' group and,
transitively, 'Users' group. That's what caused the behavior that I
observed.

Another consequence of this is that every Guest that logs-in locally
automatically becomes a member of Users group and gets its permissions
expanded to permissions of a regular User (!). In order to limit Guest's
permissions one has to place 'Deny' settings for Guests group explicitly
in all strategical places.

 

[Simon Pleasants]

Nevertheless, this turns out to be the case. More precisely, a locally
logged-in Administrator automatically becomes member of Users group. If
you take a look at your Users group, you'll see that it contains another
system group - 'NT AUTHORITY/INTERACTIVE'. Everybody who logs-in locally
automatically becomes a member of 'NT AUTHORITY/INTERACTIVE' group and,
transitively, 'Users' group. That's what caused the behavior that I
observed.

I have not yet done extensive work on this, but so far I've found that
"deny" is an extremely difficult command to implement effectively
without it having unexpected effects. So far I have managed to
circumvent the problem by simply removing the "allow" for the group in
question. In all the scenarios I have personally encountered this has
given the same effect.

So going with your original example, just don't tick "allow" in the
"write" permission settings against "users" and they won't be allowed
to write.

If this does not do what you want please let me know because it has
always worked for me!

Simon.

 

[Wesley Vogel]

Andrey;

Well, that is a moot point for me. The only users I have
active on my machine are me and the Administrator. All others
are disabled through secpol.msc.

Keep having fun.

 

[Andrey Tarasevich]

I have not yet done extensive work on this, but so far I've found that
"deny" is an extremely difficult command to implement effectively
without it having unexpected effects. So far I have managed to
circumvent the problem by simply removing the "allow" for the group in
question. In all the scenarios I have personally encountered this has
given the same effect.

So going with your original example, just don't tick "allow" in the
"write" permission settings against "users" and they won't be allowed
to write.

If this does not do what you want please let me know because it has
always worked for me!

You are right. Normally, there's no need to use 'Deny' at all as long as
you are managing users of 'Users' group or higher permission level
groups ('Power Users', 'Administrators' etc.).

But once there's a need to allow a user of lower permission level (like
a 'Guest') to log-in locally, the only way to limit his file permissions
is to use 'Deny' explicitly.

In most cases XP Pro machines don't have and don't need any 'Guests'
accounts. That's why there's is normally no need to use 'Deny' at all.
But in my case I needed to create a local account in 'Guests' group
which eventually led to the above confusion.

 

[Simon Pleasants]

You are right. Normally, there's no need to use 'Deny' at all as long as
you are managing users of 'Users' group or higher permission level
groups ('Power Users', 'Administrators' etc.).

But once there's a need to allow a user of lower permission level (like
a 'Guest') to log-in locally, the only way to limit his file permissions
is to use 'Deny' explicitly.

In most cases XP Pro machines don't have and don't need any 'Guests'
accounts. That's why there's is normally no need to use 'Deny' at all.
But in my case I needed to create a local account in 'Guests' group
which eventually led to the above confusion.

Understood. I have experimented with "deny" myself and ran into
similar problems. What I did in that instance was turn off the
inherited permissions and name the individual user giving their
account the access permissions I required thereby avoiding the issue
of group permissions altogether.