> So Windows 7 takes all the work on Vista and continues to move it forward,

> so it is worth noting that anyone thinking it will be easier to go from XP
> to Windows 7 then from XP to Vista is going to be sadly mistaken as the
> underlying security hardening that has caused issues with drivers and
> application compatibility between XP and Vista is still there under the
> cover of Windows 7, so the best and easiest migration will actually be
> from Vista to Windows 7.

Additionally, the virtualization features of Vista for legacy
support will not be carried forward to the new kernel.

"Man-wai Chang ToDie (33.6k)" <toylet.toylet@xxxxxx> wrote in message
news:%235UxUA0LJHA.5660@xxxxxx

> Under Vi$ta:
> First, I removed all accounts that could access folder X. Then I let user
> Y to take control of the folder, including subfolders. I only want Vi$ta's
> user Y to access that folder.

Was user Y elevated when you took ownership?

I've been wanting to ask the experts in this group about this
for awhile anyway, so here it goes.

When an SID is created by a limited user with an admin token
(elevated standard account) is the "owner" field different than
it would be without the admin token? In other words, is it only
possible to be accepted as the "owner" if you are attempting
access as that same user again also elevated?

> Then I boot back into XP:
> XP's Administrator as well as user could no longer access folder X, unless
> I let XP's Admin to take control of folder X. But if I did that, when I
> booted back into Vi$ta, Vi$ta's user Y could no longer access folder X.

Have you tried elevating Vista's Y user when attempting access of
folder X? Not because it needs elevated privileges, but because it
needs "owner" to match the SID - just in case the split token is what
is causing this confusion. Thereafter you should be able to allow any
standard user account you want to assume ownership.

Sorry if this isn't helpful, but maybe you would have better luck
in the micro$oft.pubic.windoze.vi$ta.insecurity newsgroup.

Hello,

That's an excellent question.

The scenarios are different depending on whether you are logged in as a
standard user or an administrator.

When logged in as a standard user, when you elevate you are logging in with
the credentials you supply to the elevation prompt and the elevated program
is running under those credentials. So, there are actually 2 SIDs involved
and things work as you described.

Things get tricky when you are logged in as an administrator. In this case,
you only have one SID, but you get 2 tokens with different privileges when
you log in. The tricky part is that in the restricted token, your group
membership in the administrators group is set to only be considered for deny
permissions.

So, the following scenario could happen:

- You are logged in as an admin
- You are running a program that is not elevated that wants to change the
permissions on a file
- You are not granted access to the file in any permission
- The administrators group owns the file

You would not be able to use the non-elevated program to change the
permissions on the file, becase your membership in the administrators group
is being ignored when the system is deciding if you should be able to have
read/change acl access to the file by virtue of being the owner.

Of course, this scenario probably wouldn't happen in real life... the
program should know to throw a UAC prompt to get elevated.

In addition, there is also the concept of integrity levels. Most
non-elevated processes are assigned medium integrity, while an elevated
process is assigned high integrity. Every file is assigned an integrity
level.

A process can only write to a file that has an equal or lower integity level
than the process, regardless of what permissions are set or who the owner
is.

So, an un-elevated process (medium integrity) could not write to or change
the permissions on a file that has high integrity, even if your SID had full
control of the file and was the owner.

(There are no files by default that have high integrity).

- JB



"FromTheRafters" <erratic@xxxxxx> wrote in message
news:u3YSsJ9LJHA.276@xxxxxx

>
> "Man-wai Chang ToDie (33.6k)" <toylet.toylet@xxxxxx> wrote in message
> news:%235UxUA0LJHA.5660@xxxxxx

>> Under Vi$ta:
>> First, I removed all accounts that could access folder X. Then I let user
>> Y to take control of the folder, including subfolders. I only want
>> Vi$ta's user Y to access that folder.

>
> Was user Y elevated when you took ownership?
>
> I've been wanting to ask the experts in this group about this
> for awhile anyway, so here it goes.
>
> When an SID is created by a limited user with an admin token
> (elevated standard account) is the "owner" field different than
> it would be without the admin token? In other words, is it only
> possible to be accepted as the "owner" if you are attempting
> access as that same user again also elevated?
>

>> Then I boot back into XP:
>> XP's Administrator as well as user could no longer access folder X,
>> unless I let XP's Admin to take control of folder X. But if I did that,
>> when I booted back into Vi$ta, Vi$ta's user Y could no longer access
>> folder X.

>
> Have you tried elevating Vista's Y user when attempting access of
> folder X? Not because it needs elevated privileges, but because it
> needs "owner" to match the SID - just in case the split token is what
> is causing this confusion. Thereafter you should be able to allow any
> standard user account you want to assume ownership.
>
> Sorry if this isn't helpful, but maybe you would have better luck
> in the micro$oft.pubic.windoze.vi$ta.insecurity newsgroup.
>

> (There are no files by default that have high integrity).

I was wrong. Any file that you create in the root of your system drive has
high integrity.

- JB

Thanks for your answer Jimmy.

Having read this:

http://www.microsoft.com/technet/pro....mspx?mfr=true

....it had me wondering how things may have changed re Vista.

"Jimmy Brush" <jb@xxxxxx> wrote in message
news:eSHYjY%23LJHA.4772@xxxxxx

> Hello,
>
> That's an excellent question.
>
> The scenarios are different depending on whether you are logged in as a
> standard user or an administrator.
>
> When logged in as a standard user, when you elevate you are logging in
> with the credentials you supply to the elevation prompt and the elevated
> program is running under those credentials. So, there are actually 2 SIDs
> involved and things work as you described.
>
> Things get tricky when you are logged in as an administrator. In this
> case, you only have one SID, but you get 2 tokens with different
> privileges when you log in. The tricky part is that in the restricted
> token, your group membership in the administrators group is set to only be
> considered for deny permissions.
>
> So, the following scenario could happen:
>
> - You are logged in as an admin
> - You are running a program that is not elevated that wants to change the
> permissions on a file
> - You are not granted access to the file in any permission
> - The administrators group owns the file
>
> You would not be able to use the non-elevated program to change the
> permissions on the file, becase your membership in the administrators
> group is being ignored when the system is deciding if you should be able
> to have read/change acl access to the file by virtue of being the owner.
>
> Of course, this scenario probably wouldn't happen in real life... the
> program should know to throw a UAC prompt to get elevated.
>
> In addition, there is also the concept of integrity levels. Most
> non-elevated processes are assigned medium integrity, while an elevated
> process is assigned high integrity. Every file is assigned an integrity
> level.
>
> A process can only write to a file that has an equal or lower integity
> level than the process, regardless of what permissions are set or who the
> owner is.
>
> So, an un-elevated process (medium integrity) could not write to or change
> the permissions on a file that has high integrity, even if your SID had
> full control of the file and was the owner.
>
> (There are no files by default that have high integrity).
>
> - JB
>
>
>
> "FromTheRafters" <erratic@xxxxxx> wrote in message
> news:u3YSsJ9LJHA.276@xxxxxx

>>
>> "Man-wai Chang ToDie (33.6k)" <toylet.toylet@xxxxxx> wrote in message
>> news:%235UxUA0LJHA.5660@xxxxxx

>>> Under Vi$ta:
>>> First, I removed all accounts that could access folder X. Then I let
>>> user Y to take control of the folder, including subfolders. I only want
>>> Vi$ta's user Y to access that folder.

>>
>> Was user Y elevated when you took ownership?
>>
>> I've been wanting to ask the experts in this group about this
>> for awhile anyway, so here it goes.
>>
>> When an SID is created by a limited user with an admin token
>> (elevated standard account) is the "owner" field different than
>> it would be without the admin token? In other words, is it only
>> possible to be accepted as the "owner" if you are attempting
>> access as that same user again also elevated?
>>

>>> Then I boot back into XP:
>>> XP's Administrator as well as user could no longer access folder X,
>>> unless I let XP's Admin to take control of folder X. But if I did that,
>>> when I booted back into Vi$ta, Vi$ta's user Y could no longer access
>>> folder X.

>>
>> Have you tried elevating Vista's Y user when attempting access of
>> folder X? Not because it needs elevated privileges, but because it
>> needs "owner" to match the SID - just in case the split token is what
>> is causing this confusion. Thereafter you should be able to allow any
>> standard user account you want to assume ownership.
>>
>> Sorry if this isn't helpful, but maybe you would have better luck
>> in the micro$oft.pubic.windoze.vi$ta.insecurity newsgroup.
>>

>

If you are logged in as an administrator:

- If the program is not elevated, the owner on a new file it creates will be
the admin user SID
- If the program is elevated, the owner will be the administrators group

If you are logged in as a standard user:

- If the program is not elevated, the owner on a new file it creates will be
the standard user SID
- If the program is elevated, the owner will be the administrators group

- JB


"FromTheRafters" <erratic@xxxxxx> wrote in message
news:exUKQk%23LJHA.4772@xxxxxx

> Thanks for your answer Jimmy.
>
> Having read this:
>
> http://www.microsoft.com/technet/pro....mspx?mfr=true
>
> ...it had me wondering how things may have changed re Vista.
>
> "Jimmy Brush" <jb@xxxxxx> wrote in message
> news:eSHYjY%23LJHA.4772@xxxxxx

>> Hello,
>>
>> That's an excellent question.
>>
>> The scenarios are different depending on whether you are logged in as a
>> standard user or an administrator.
>>
>> When logged in as a standard user, when you elevate you are logging in
>> with the credentials you supply to the elevation prompt and the elevated
>> program is running under those credentials. So, there are actually 2 SIDs
>> involved and things work as you described.
>>
>> Things get tricky when you are logged in as an administrator. In this
>> case, you only have one SID, but you get 2 tokens with different
>> privileges when you log in. The tricky part is that in the restricted
>> token, your group membership in the administrators group is set to only
>> be considered for deny permissions.
>>
>> So, the following scenario could happen:
>>
>> - You are logged in as an admin
>> - You are running a program that is not elevated that wants to change the
>> permissions on a file
>> - You are not granted access to the file in any permission
>> - The administrators group owns the file
>>
>> You would not be able to use the non-elevated program to change the
>> permissions on the file, becase your membership in the administrators
>> group is being ignored when the system is deciding if you should be able
>> to have read/change acl access to the file by virtue of being the owner.
>>
>> Of course, this scenario probably wouldn't happen in real life... the
>> program should know to throw a UAC prompt to get elevated.
>>
>> In addition, there is also the concept of integrity levels. Most
>> non-elevated processes are assigned medium integrity, while an elevated
>> process is assigned high integrity. Every file is assigned an integrity
>> level.
>>
>> A process can only write to a file that has an equal or lower integity
>> level than the process, regardless of what permissions are set or who the
>> owner is.
>>
>> So, an un-elevated process (medium integrity) could not write to or
>> change the permissions on a file that has high integrity, even if your
>> SID had full control of the file and was the owner.
>>
>> (There are no files by default that have high integrity).
>>
>> - JB
>>
>>
>>
>> "FromTheRafters" <erratic@xxxxxx> wrote in message
>> news:u3YSsJ9LJHA.276@xxxxxx

>>>
>>> "Man-wai Chang ToDie (33.6k)" <toylet.toylet@xxxxxx> wrote in message
>>> news:%235UxUA0LJHA.5660@xxxxxx
>>>> Under Vi$ta:
>>>> First, I removed all accounts that could access folder X. Then I let
>>>> user Y to take control of the folder, including subfolders. I only want
>>>> Vi$ta's user Y to access that folder.
>>>
>>> Was user Y elevated when you took ownership?
>>>
>>> I've been wanting to ask the experts in this group about this
>>> for awhile anyway, so here it goes.
>>>
>>> When an SID is created by a limited user with an admin token
>>> (elevated standard account) is the "owner" field different than
>>> it would be without the admin token? In other words, is it only
>>> possible to be accepted as the "owner" if you are attempting
>>> access as that same user again also elevated?
>>>
>>>> Then I boot back into XP:
>>>> XP's Administrator as well as user could no longer access folder X,
>>>> unless I let XP's Admin to take control of folder X. But if I did that,
>>>> when I booted back into Vi$ta, Vi$ta's user Y could no longer access
>>>> folder X.
>>>
>>> Have you tried elevating Vista's Y user when attempting access of
>>> folder X? Not because it needs elevated privileges, but because it
>>> needs "owner" to match the SID - just in case the split token is what
>>> is causing this confusion. Thereafter you should be able to allow any
>>> standard user account you want to assume ownership.
>>>
>>> Sorry if this isn't helpful, but maybe you would have better luck
>>> in the micro$oft.pubic.windoze.vi$ta.insecurity newsgroup.
>>>

>>

>
>

Also, you can assign ownership to an arbitrary user or group in Vista
through the ACL editor UI, with the appropriate rights of course.

- JB


"FromTheRafters" <erratic@xxxxxx> wrote in message
news:exUKQk%23LJHA.4772@xxxxxx

> Thanks for your answer Jimmy.
>
> Having read this:
>
> http://www.microsoft.com/technet/pro....mspx?mfr=true
>
> ...it had me wondering how things may have changed re Vista.
>
> "Jimmy Brush" <jb@xxxxxx> wrote in message
> news:eSHYjY%23LJHA.4772@xxxxxx

>> Hello,
>>
>> That's an excellent question.
>>
>> The scenarios are different depending on whether you are logged in as a
>> standard user or an administrator.
>>
>> When logged in as a standard user, when you elevate you are logging in
>> with the credentials you supply to the elevation prompt and the elevated
>> program is running under those credentials. So, there are actually 2 SIDs
>> involved and things work as you described.
>>
>> Things get tricky when you are logged in as an administrator. In this
>> case, you only have one SID, but you get 2 tokens with different
>> privileges when you log in. The tricky part is that in the restricted
>> token, your group membership in the administrators group is set to only
>> be considered for deny permissions.
>>
>> So, the following scenario could happen:
>>
>> - You are logged in as an admin
>> - You are running a program that is not elevated that wants to change the
>> permissions on a file
>> - You are not granted access to the file in any permission
>> - The administrators group owns the file
>>
>> You would not be able to use the non-elevated program to change the
>> permissions on the file, becase your membership in the administrators
>> group is being ignored when the system is deciding if you should be able
>> to have read/change acl access to the file by virtue of being the owner.
>>
>> Of course, this scenario probably wouldn't happen in real life... the
>> program should know to throw a UAC prompt to get elevated.
>>
>> In addition, there is also the concept of integrity levels. Most
>> non-elevated processes are assigned medium integrity, while an elevated
>> process is assigned high integrity. Every file is assigned an integrity
>> level.
>>
>> A process can only write to a file that has an equal or lower integity
>> level than the process, regardless of what permissions are set or who the
>> owner is.
>>
>> So, an un-elevated process (medium integrity) could not write to or
>> change the permissions on a file that has high integrity, even if your
>> SID had full control of the file and was the owner.
>>
>> (There are no files by default that have high integrity).
>>
>> - JB
>>
>>
>>
>> "FromTheRafters" <erratic@xxxxxx> wrote in message
>> news:u3YSsJ9LJHA.276@xxxxxx

>>>
>>> "Man-wai Chang ToDie (33.6k)" <toylet.toylet@xxxxxx> wrote in message
>>> news:%235UxUA0LJHA.5660@xxxxxx
>>>> Under Vi$ta:
>>>> First, I removed all accounts that could access folder X. Then I let
>>>> user Y to take control of the folder, including subfolders. I only want
>>>> Vi$ta's user Y to access that folder.
>>>
>>> Was user Y elevated when you took ownership?
>>>
>>> I've been wanting to ask the experts in this group about this
>>> for awhile anyway, so here it goes.
>>>
>>> When an SID is created by a limited user with an admin token
>>> (elevated standard account) is the "owner" field different than
>>> it would be without the admin token? In other words, is it only
>>> possible to be accepted as the "owner" if you are attempting
>>> access as that same user again also elevated?
>>>
>>>> Then I boot back into XP:
>>>> XP's Administrator as well as user could no longer access folder X,
>>>> unless I let XP's Admin to take control of folder X. But if I did that,
>>>> when I booted back into Vi$ta, Vi$ta's user Y could no longer access
>>>> folder X.
>>>
>>> Have you tried elevating Vista's Y user when attempting access of
>>> folder X? Not because it needs elevated privileges, but because it
>>> needs "owner" to match the SID - just in case the split token is what
>>> is causing this confusion. Thereafter you should be able to allow any
>>> standard user account you want to assume ownership.
>>>
>>> Sorry if this isn't helpful, but maybe you would have better luck
>>> in the micro$oft.pubic.windoze.vi$ta.insecurity newsgroup.
>>>

>>

>
>

So, this is the reason a user cannot use IE to download
a program file and save it to the C:\ directory? It is not
UAC/permissions/ownership but rather integrity level
with NO_WRITE_UP (from IE to C:\ )?

But UAC gets blamed for everything. )

"Jimmy Brush" <jb@xxxxxx> wrote in message
news:ee%230Pi%23LJHA.4772@xxxxxx

>> (There are no files by default that have high integrity).

>
> I was wrong. Any file that you create in the root of your system drive has
> high integrity.
>
> - JB

Can you confirm this? It was my understanding that you can
only grant the permission for another to take ownership and
not simply assign ownership to another (for auditing purposes
to avoid someone taking ownership, making nefarious changes
and then assigning ownership to a scapegoat).

....again, this was from the W2K link - but I don't see why
that would change in Vista (unless they've improved on the
audit trail).

"Jimmy Brush" <jb@xxxxxx> wrote in message
news:Os9bZ1%23LJHA.3080@xxxxxx

> Also, you can assign ownership to an arbitrary user or group in Vista
> through the ACL editor UI, with the appropriate rights of course.
>
> - JB
>
>
> "FromTheRafters" <erratic@xxxxxx> wrote in message
> news:exUKQk%23LJHA.4772@xxxxxx

>> Thanks for your answer Jimmy.
>>
>> Having read this:
>>
>> http://www.microsoft.com/technet/pro....mspx?mfr=true
>>
>> ...it had me wondering how things may have changed re Vista.
>>
>> "Jimmy Brush" <jb@xxxxxx> wrote in message
>> news:eSHYjY%23LJHA.4772@xxxxxx

>>> Hello,
>>>
>>> That's an excellent question.
>>>
>>> The scenarios are different depending on whether you are logged in as a
>>> standard user or an administrator.
>>>
>>> When logged in as a standard user, when you elevate you are logging in
>>> with the credentials you supply to the elevation prompt and the elevated
>>> program is running under those credentials. So, there are actually 2
>>> SIDs involved and things work as you described.
>>>
>>> Things get tricky when you are logged in as an administrator. In this
>>> case, you only have one SID, but you get 2 tokens with different
>>> privileges when you log in. The tricky part is that in the restricted
>>> token, your group membership in the administrators group is set to only
>>> be considered for deny permissions.
>>>
>>> So, the following scenario could happen:
>>>
>>> - You are logged in as an admin
>>> - You are running a program that is not elevated that wants to change
>>> the permissions on a file
>>> - You are not granted access to the file in any permission
>>> - The administrators group owns the file
>>>
>>> You would not be able to use the non-elevated program to change the
>>> permissions on the file, becase your membership in the administrators
>>> group is being ignored when the system is deciding if you should be able
>>> to have read/change acl access to the file by virtue of being the owner.
>>>
>>> Of course, this scenario probably wouldn't happen in real life... the
>>> program should know to throw a UAC prompt to get elevated.
>>>
>>> In addition, there is also the concept of integrity levels. Most
>>> non-elevated processes are assigned medium integrity, while an elevated
>>> process is assigned high integrity. Every file is assigned an integrity
>>> level.
>>>
>>> A process can only write to a file that has an equal or lower integity
>>> level than the process, regardless of what permissions are set or who
>>> the owner is.
>>>
>>> So, an un-elevated process (medium integrity) could not write to or
>>> change the permissions on a file that has high integrity, even if your
>>> SID had full control of the file and was the owner.
>>>
>>> (There are no files by default that have high integrity).
>>>
>>> - JB
>>>
>>>
>>>
>>> "FromTheRafters" <erratic@xxxxxx> wrote in message
>>> news:u3YSsJ9LJHA.276@xxxxxx
>>>>
>>>> "Man-wai Chang ToDie (33.6k)" <toylet.toylet@xxxxxx> wrote in
>>>> message news:%235UxUA0LJHA.5660@xxxxxx
>>>>> Under Vi$ta:
>>>>> First, I removed all accounts that could access folder X. Then I let
>>>>> user Y to take control of the folder, including subfolders. I only
>>>>> want Vi$ta's user Y to access that folder.
>>>>
>>>> Was user Y elevated when you took ownership?
>>>>
>>>> I've been wanting to ask the experts in this group about this
>>>> for awhile anyway, so here it goes.
>>>>
>>>> When an SID is created by a limited user with an admin token
>>>> (elevated standard account) is the "owner" field different than
>>>> it would be without the admin token? In other words, is it only
>>>> possible to be accepted as the "owner" if you are attempting
>>>> access as that same user again also elevated?
>>>>
>>>>> Then I boot back into XP:
>>>>> XP's Administrator as well as user could no longer access folder X,
>>>>> unless I let XP's Admin to take control of folder X. But if I did
>>>>> that, when I booted back into Vi$ta, Vi$ta's user Y could no longer
>>>>> access folder X.
>>>>
>>>> Have you tried elevating Vista's Y user when attempting access of
>>>> folder X? Not because it needs elevated privileges, but because it
>>>> needs "owner" to match the SID - just in case the split token is what
>>>> is causing this confusion. Thereafter you should be able to allow any
>>>> standard user account you want to assume ownership.
>>>>
>>>> Sorry if this isn't helpful, but maybe you would have better luck
>>>> in the micro$oft.pubic.windoze.vi$ta.insecurity newsgroup.
>>>>
>>>

>>
>>

>

Yup . You have to hold the restore privilege (admins have it by default).

This isn't new functionality to Vista, it was just never exposed in the UI
before.

http://support.microsoft.com/kb/245153/EN-US/

I am not aware of any auditing enhancements.

- JB

"FromTheRafters" <erratic@xxxxxx> wrote in message
news:%23RqSSMJMJHA.3744@xxxxxx

> Can you confirm this? It was my understanding that you can
> only grant the permission for another to take ownership and
> not simply assign ownership to another (for auditing purposes
> to avoid someone taking ownership, making nefarious changes
> and then assigning ownership to a scapegoat).
>
> ...again, this was from the W2K link - but I don't see why
> that would change in Vista (unless they've improved on the
> audit trail).
>
> "Jimmy Brush" <jb@xxxxxx> wrote in message
> news:Os9bZ1%23LJHA.3080@xxxxxx

>> Also, you can assign ownership to an arbitrary user or group in Vista
>> through the ACL editor UI, with the appropriate rights of course.
>>
>> - JB
>>
>>
>> "FromTheRafters" <erratic@xxxxxx> wrote in message
>> news:exUKQk%23LJHA.4772@xxxxxx

>>> Thanks for your answer Jimmy.
>>>
>>> Having read this:
>>>
>>> http://www.microsoft.com/technet/pro....mspx?mfr=true
>>>
>>> ...it had me wondering how things may have changed re Vista.
>>>
>>> "Jimmy Brush" <jb@xxxxxx> wrote in message
>>> news:eSHYjY%23LJHA.4772@xxxxxx
>>>> Hello,
>>>>
>>>> That's an excellent question.
>>>>
>>>> The scenarios are different depending on whether you are logged in as a
>>>> standard user or an administrator.
>>>>
>>>> When logged in as a standard user, when you elevate you are logging in
>>>> with the credentials you supply to the elevation prompt and the
>>>> elevated program is running under those credentials. So, there are
>>>> actually 2 SIDs involved and things work as you described.
>>>>
>>>> Things get tricky when you are logged in as an administrator. In this
>>>> case, you only have one SID, but you get 2 tokens with different
>>>> privileges when you log in. The tricky part is that in the restricted
>>>> token, your group membership in the administrators group is set to only
>>>> be considered for deny permissions.
>>>>
>>>> So, the following scenario could happen:
>>>>
>>>> - You are logged in as an admin
>>>> - You are running a program that is not elevated that wants to change
>>>> the permissions on a file
>>>> - You are not granted access to the file in any permission
>>>> - The administrators group owns the file
>>>>
>>>> You would not be able to use the non-elevated program to change the
>>>> permissions on the file, becase your membership in the administrators
>>>> group is being ignored when the system is deciding if you should be
>>>> able to have read/change acl access to the file by virtue of being the
>>>> owner.
>>>>
>>>> Of course, this scenario probably wouldn't happen in real life... the
>>>> program should know to throw a UAC prompt to get elevated.
>>>>
>>>> In addition, there is also the concept of integrity levels. Most
>>>> non-elevated processes are assigned medium integrity, while an elevated
>>>> process is assigned high integrity. Every file is assigned an integrity
>>>> level.
>>>>
>>>> A process can only write to a file that has an equal or lower integity
>>>> level than the process, regardless of what permissions are set or who
>>>> the owner is.
>>>>
>>>> So, an un-elevated process (medium integrity) could not write to or
>>>> change the permissions on a file that has high integrity, even if your
>>>> SID had full control of the file and was the owner.
>>>>
>>>> (There are no files by default that have high integrity).
>>>>
>>>> - JB
>>>>
>>>>
>>>>
>>>> "FromTheRafters" <erratic@xxxxxx> wrote in message
>>>> news:u3YSsJ9LJHA.276@xxxxxx
>>>>>
>>>>> "Man-wai Chang ToDie (33.6k)" <toylet.toylet@xxxxxx> wrote in
>>>>> message news:%235UxUA0LJHA.5660@xxxxxx
>>>>>> Under Vi$ta:
>>>>>> First, I removed all accounts that could access folder X. Then I let
>>>>>> user Y to take control of the folder, including subfolders. I only
>>>>>> want Vi$ta's user Y to access that folder.
>>>>>
>>>>> Was user Y elevated when you took ownership?
>>>>>
>>>>> I've been wanting to ask the experts in this group about this
>>>>> for awhile anyway, so here it goes.
>>>>>
>>>>> When an SID is created by a limited user with an admin token
>>>>> (elevated standard account) is the "owner" field different than
>>>>> it would be without the admin token? In other words, is it only
>>>>> possible to be accepted as the "owner" if you are attempting
>>>>> access as that same user again also elevated?
>>>>>
>>>>>> Then I boot back into XP:
>>>>>> XP's Administrator as well as user could no longer access folder X,
>>>>>> unless I let XP's Admin to take control of folder X. But if I did
>>>>>> that, when I booted back into Vi$ta, Vi$ta's user Y could no longer
>>>>>> access folder X.
>>>>>
>>>>> Have you tried elevating Vista's Y user when attempting access of
>>>>> folder X? Not because it needs elevated privileges, but because it
>>>>> needs "owner" to match the SID - just in case the split token is what
>>>>> is causing this confusion. Thereafter you should be able to allow any
>>>>> standard user account you want to assume ownership.
>>>>>
>>>>> Sorry if this isn't helpful, but maybe you would have better luck
>>>>> in the micro$oft.pubic.windoze.vi$ta.insecurity newsgroup.
>>>>>
>>>>
>>>
>>>

>>

>
>