XP Group/File Permissions (Possible BUG found)

  • Thread starter Thread starter adbdollar
  • Start date Start date
A

adbdollar

The machine runs:
Windows XP Professional Service Pack 1 with all the
recommended and security patches
as of 02/15/2004


Example of the problem:

After creating a group lets say called "Apps", and then
adding a few users, like "Administrator"
or "user1", "user2" etc... to this new group

Then assigning Permissions to a directory so that
group "Apps" has full Access, and of course all members
of this group should also have full access.

However, this new permission scheme will not be reconized
and take effect, unless the system is rebooted.

What I mean is, the system will prevent any user in the
new group from accessing the directory with the new group
permissions, until a system reboot.

After I reboot, the new permission strategy is in force,
and every thing works fine.

This is not very useful, as not everyone can afford to
reboot machines, everytime they need to secure a
directory or application.

This seems like a bug, as one would expect it to be
enforce, the moment one changes the permissions.

However, I am also aware that some features that seem
like a bug, are really features by design, and although
that may be reasonable in some cases, this certainly can
not be one of those.

Well, one would expect it would not be.

I can repeat this process as many times as one likes, and
have even re-installed with the same outcome.

Any suggestions?
 
When a user logs into a system, they are issued a token which essentially
contains a listing of all the groups they are a part of.

Adding a user to a group requires them to log off and back on (to either the
local system or the domain, depending on your situation) to receive the
updated token.

I think that's what's causing your problem.

This is well documented and by design. Common test question on MCP exams
too ;)
 
Hmmm, so from your response you seem to support this
feature of having to reboot every time one modifies
groups and permissions. I guess thats the easy solution
to call it by design, but it does not change the fact that
the feature sucks, and causes disruption in a production
environment.

I think I will stay with UNIX, as it just does not have
these problems. Oh, and its on the UNIX certification
exams as well.


LOL FRUITCAKE!!!
 
I understand In a domain that contains more than one
domain controller, Active Directory information takes
time to propagate from one domain controller to another.

however to prove there is a lacking capability in the
design of authentication and verification just do the
following on a standalone machine that uses no domain
controllers for authentication.

Create a group on a standalone machine, then add some
users to the group. next, use cacls and modify the ACLs
for a given directory to permit full access to that new
group.

Then, go ahead and see if you can access the directory.

You will see that you will not be able to, but if you
reboot, you can.
 
Yes I am aware of that (I even did that exact experiment before typing my
previous reply to make sure I understood what was reported)... the newly
added users in the group will have access the next time they authenticate.
Once again, a full reboot is overkill.
 
Ok, so you say re-authenticate, and reboots are overkill,
I agree that reboots are overkill, however the problem
is, that a properly designed mechanism, would allow for
the modification of some security context, without having
to manually re-authenticate to update the relationship
between the token information (privledges), and the
process or thread.

I mean, it appears that once the ACL's are associated
with the group, or vice versa, that the security
attributes in force are not made known to the system,
unless further manual interaction is performed.

This is undesirable, because logging off and back on or
rebooting causes much pain especially, when many tasks
need to be performed in series, verifying the success
through each. For example one may want to secure many
objects, but verify the success of each along the way.

Having to manually re-authenticate seems much like a
burden.
 
with the group, or vice versa, that the security
attributes in force are not made known to the system,
unless further manual interaction is performed.
Click to expand...

This is immediate. You need to re-authenticate when the user is associated
with the group.



This is undesirable, because logging off and back on or
rebooting causes much pain especially, when many tasks
need to be performed in series, verifying the success
through each. For example one may want to secure many
objects, but verify the success of each along the way.

Having to manually re-authenticate seems much like a
burden.
Click to expand...

The only way to implement your solution would be for the system to check
with the domain controller see if the user's token has changed each time a
resource is accessed. Maybe this could occur silently in the background but
the performance hit on a large network would be massive, with each
workstation constantly hitting the domain controllers.

I've read some good technet/msdn articles about this that really explained
the reasons for the design quite well. I looked and looked but can't find
them for you.

You could always send an email to (e-mail address removed) with your suggestions
:)
 
And that is the aspect that is lacking, because if the
SID of the user account has not changed, and was granted
permission to create the new security context, why then
is there a need to re-authenticate?
 
His SID hasn't changed but his token contains his SID and the SID of all the
groups he is part of.

The ACL is checked against the token, not the user's account (SID) directly.

I don't work for Microsoft so convincing me that there is a better way to do
this won't do much.

I can tell you that in my experience, this hasn't caused any real problem.
Users needs access to something? OK add them to the group and tell them its
available next time they log in.

Want to look at the flip side? Remove them from the group but they still
have access until they reauthenticate. That's a bit more of a concern.
 
Well you see, thats my whole point, the facility is
lacking and to me the goal of making it known is to make
it better, more reliable, and functional.

Do not worry, my goal was not to convince you, but rather
share my thoughts on the matter in hopes of maybe someone
else searching these archives, may have an understanding
if they encounter the same issue.

Anyway I am sure if this issue is of concern to others,
they too might make it known....:)

Cheers!
 
Back
Top