Adding XP in another partition users into Vi$ta

[Man-wai Chang ToDie (33.6k)]

I am dual booting 32-bit XP and 64-bit Vi$ta. I wanna create a folder
that's readable by an account of the same name from both XP and Vista.

How should I do it when I boot Vi$ta?

I think I had possibly asked the same question before but I forgot....

--
@~@ Might, Courage, Vision, SINCERITY.
/ v \ Simplicity is Beauty! May the Force and Farce be with you!
/( _ )\ (Xubuntu 8.04.1) Linux 2.6.26.6
^ ^ 19:54:01 up 2 days 4:37 2 users load average: 1.00 1.02 1.00
ä¸å€Ÿè²¸! ä¸è©é¨™! ä¸æ´äº¤! ä¸æ‰“交! ä¸æ‰“劫! ä¸è‡ªæ®º! è«‹è€ƒæ…®ç¶œæ´ (CSSA):
http://www.swd.gov.hk/tc/index/site_pubsvc/page_socsecu/sub_addressesa

 

[Mike Brannigan]

You can't. You will just have to give the everyone object permission to the
folder. You cannot secure it against the security principals from the other
OS as it is not active or contactable from the one running OS.
The name of the account is irrelevant as it is actually the objects Security
ID (SID) that is placed on the Access Control Entry (ACE) on the Access
Control List (ACL) for the folder object.

(Also you appear to have a problem spelling Vista - it is an s not a $
unless you are trying to be cute like the idiots that put a $ in Microsoft.
If you have a point to make about the product do it elsewhere, if you want
to ask questions then just try referring to the product and company by their
correct names).
--
Mike Brannigan

"Man-wai Chang ToDie (33.6k)" <toylet.toylet@gmail.com> wrote in message
news:Oet8mPfLJHA.456@TK2MSFTNGP06.phx.gbl...
>
> I am dual booting 32-bit XP and 64-bit Vi$ta. I wanna create a folder
> that's readable by an account of the same name from both XP and Vista.
>
> How should I do it when I boot Vi$ta?
>
> I think I had possibly asked the same question before but I forgot....
>
> --
> @~@ Might, Courage, Vision, SINCERITY.
> / v \ Simplicity is Beauty! May the Force and Farce be with you!
> /( _ )\ (Xubuntu 8.04.1) Linux 2.6.26.6
> ^ ^ 19:54:01 up 2 days 4:37 2 users load average: 1.00 1.02 1.00
> ä¸å€Ÿè²¸! ä¸è©é¨™! ä¸æ´äº¤! ä¸æ‰“交! ä¸æ‰“劫! ä¸è‡ªæ®º! è«‹è€ƒæ…®ç¶œæ´ (CSSA):
> http://www.swd.gov.hk/tc/index/site_pubsvc/page_socsecu/sub_addressesa

 

[Man-wai Chang ToDie (33.6k)]

> You can't. You will just have to give the everyone object permission to
> the folder. You cannot secure it against the security principals from
> the other OS as it is not active or contactable from the one running OS.
> The name of the account is irrelevant as it is actually the objects
> Security ID (SID) that is placed on the Access Control Entry (ACE) on
> the Access Control List (ACL) for the folder object.

Both Vi$ta and XP use the same NTFS file systems. Can't the security
wizard open the user database in another partition and extract the
relevant information?

> (Also you appear to have a problem spelling Vista - it is an s not a $
> unless you are trying to be cute like the idiots that put a $ in
> Microsoft. If you have a point to make about the product do it
> elsewhere, if you want to ask questions then just try referring to the
> product and company by their correct names).

I am not trying to be cute nor trying to promote anything. I will
continue addressing it as Vi$ta. I did spend over HK$2000 to buy my
Vi$ta Ultimate Upgrade, which would likely end up as WinMe.....

--
@~@ Might, Courage, Vision, SINCERITY.
/ v \ Simplicity is Beauty! May the Force and Farce be with you!
/( _ )\ (Xubuntu 8.04.1) Linux 2.6.26.6
^ ^ 22:19:01 up 3 days 7:02 2 users load average: 1.02 1.04 1.00
ä¸å€Ÿè²¸! ä¸è©é¨™! ä¸æ´äº¤! ä¸æ‰“交! ä¸æ‰“劫! ä¸è‡ªæ®º! è«‹è€ƒæ…®ç¶œæ´ (CSSA):
http://www.swd.gov.hk/tc/index/site_pubsvc/page_socsecu/sub_addressesa

 

[Mike Brannigan]

"Man-wai Chang ToDie (33.6k)" <toylet.toylet@gmail.com> wrote in message
news:uZ7lZFtLJHA.4772@TK2MSFTNGP06.phx.gbl...
>> You can't. You will just have to give the everyone object permission to
>> the folder. You cannot secure it against the security principals from
>> the other OS as it is not active or contactable from the one running OS.
>> The name of the account is irrelevant as it is actually the objects
>> Security ID (SID) that is placed on the Access Control Entry (ACE) on the
>> Access Control List (ACL) for the folder object.
>
> Both Vi$ta and XP use the same NTFS file systems. Can't the security
> wizard open the user database in another partition and extract the
> relevant information?
>

No. The Security Account Manager (SAM) database on an instance of Windows
is more then a file to open. So one running instance on your PC cannot
access the SAM in the other operating system. If you want true cross
instance security management then you need to a move to a domain model with
Windows Servers building a shared directory service for all machines and
operating system instances, an Active Directory. (No you cannot "run" an
Active Directory in a client PC OS like XP or Vista, it is a server only
function)
Bascially within a running OS that is in a workgroup or none networked
environment the only security principals it has access to are those in its
own SAM and for other systems to access files or folder secured using NTFS
ACLs then you need to use account objects such as Guest or Everyone etc

>> (Also you appear to have a problem spelling Vista - it is an s not a $
>> unless you are trying to be cute like the idiots that put a $ in
>> Microsoft. If you have a point to make about the product do it elsewhere,
>> if you want to ask questions then just try referring to the product and
>> company by their correct names).
>
> I am not trying to be cute nor trying to promote anything. I will continue
> addressing it as Vi$ta. I did spend over HK$2000 to buy my Vi$ta Ultimate
> Upgrade, which would likely end up as WinMe.....
>

Well it lacks respect.
As regards your Vista Ultimate becoming like Windows ME - there is no
possibility of that. Windows ME was a dead end product at the end of the
Win 9x product line. Windows Vista is the ongoing development of the NT
desktop operating lineage from Windows NT via Windows 2000 and Windows XP to
where we are today and onward to Windows 7 and future releases. All
effectively built on generational models of the kernel (with some backports
and cross development from the server team) and ongoing security tightening
and innovation. 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.
So no, your Windows Vista will not end up like ME.

> --
> @~@ Might, Courage, Vision, SINCERITY.
> / v \ Simplicity is Beauty! May the Force and Farce be with you!
> /( _ )\ (Xubuntu 8.04.1) Linux 2.6.26.6
> ^ ^ 22:19:01 up 3 days 7:02 2 users load average: 1.02 1.04 1.00
> ä¸å€Ÿè²¸! ä¸è©é¨™! ä¸æ´äº¤! ä¸æ‰“交! ä¸æ‰“劫! ä¸è‡ªæ®º! è«‹è€ƒæ…®ç¶œæ´ (CSSA):
> http://www.swd.gov.hk/tc/index/site_pubsvc/page_socsecu/sub_addressesa

--

Mike Brannigan

 

[FromTheRafters]

> 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.

 

[Jimmy Brush]

Hello,

The common account groups are recognized between installations of Windows
(like Users and Administrators).

As long as the administrators group has full control of the file or folder,
you can add specific permissions to the object from any Windows
installation.

For example, create a folder in XP, and then in Vista add a permission to
that folder giving your Vista user account permission.

I STRONGLY CAUTION you to not change the owner of files created in another
Windows installation. This could really muck things up.

- JB


"Man-wai Chang ToDie (33.6k)" <toylet.toylet@gmail.com> wrote in message
news:Oet8mPfLJHA.456@TK2MSFTNGP06.phx.gbl...
>
> I am dual booting 32-bit XP and 64-bit Vi$ta. I wanna create a folder
> that's readable by an account of the same name from both XP and Vista.
>
> How should I do it when I boot Vi$ta?
>
> I think I had possibly asked the same question before but I forgot....
>
> --
> @~@ Might, Courage, Vision, SINCERITY.
> / v \ Simplicity is Beauty! May the Force and Farce be with you!
> /( _ )\ (Xubuntu 8.04.1) Linux 2.6.26.6
> ^ ^ 19:54:01 up 2 days 4:37 2 users load average: 1.00 1.02 1.00
> ä¸å€Ÿè²¸! ä¸è©é¨™! ä¸æ´äº¤! ä¸æ‰“交! ä¸æ‰“劫! ä¸è‡ªæ®º! è«‹è€ƒæ…®ç¶œæ´ (CSSA):
> http://www.swd.gov.hk/tc/index/site_pubsvc/page_socsecu/sub_addressesa

 

[Man-wai Chang ToDie (33.6k)]

> I STRONGLY CAUTION you to not change the owner of files created in
> another Windows installation. This could really muck things up.

Too late. I did it, in that I removed the Administrator accounts from
that folder. And it seems that it's quite hard to undo the damage. ANd
that's why I asked, in that I wanna undo the damage.

--
@~@ Might, Courage, Vision, SINCERITY.
/ v \ Simplicity is Beauty! May the Force and Farce be with you!
/( _ )\ (Xubuntu 8.04.1) Linux 2.6.26.6
^ ^ 10:31:02 up 3 days 19:14 3 users load average: 3.02 2.82 2.51
???! ???! ???! ???! ???! ???! ????? (CSSA):
http://www.swd.gov.hk/tc/index/site_pubsvc/page_socsecu/sub_addressesa

 

[Man-wai Chang ToDie (33.6k)]

> No. The Security Account Manager (SAM) database on an instance of
> Windows is more then a file to open. So one running instance on your PC
> cannot access the SAM in the other operating system. If you want true
> cross instance security management then you need to a move to a domain
> model with Windows Servers building a shared directory service for all
> machines and operating system instances, an Active Directory. (No you
> cannot "run" an Active Directory in a client PC OS like XP or Vista, it
> is a server only function)
> Bascially within a running OS that is in a workgroup or none networked
> environment the only security principals it has access to are those in
> its own SAM and for other systems to access files or folder secured
> using NTFS ACLs then you need to use account objects such as Guest or
> Everyone etc

It's just my PC, so I would not set up a domain/AD server. Besides, I am
using Linux as a home server+router.

--
@~@ Might, Courage, Vision, SINCERITY.
/ v \ Simplicity is Beauty! May the Force and Farce be with you!
/( _ )\ (Xubuntu 8.04.1) Linux 2.6.26.6
^ ^ 10:32:01 up 3 days 19:15 3 users load average: 2.80 2.80 2.52
???! ???! ???! ???! ???! ???! ????? (CSSA):
http://www.swd.gov.hk/tc/index/site_pubsvc/page_socsecu/sub_addressesa

 

[Man-wai Chang ToDie (33.6k)]

Re: Vi[$]ta

> Well it lacks respect.

Vi$ta is not cheap. Definitely not free as Linux. For me, it's just a
name. Did you know some people nicknamed Window$ as "WinTendo"? In fact,
at home, my 64-bit Vi$ta is more like a game console.

> As regards your Vista Ultimate becoming like Windows ME - there is no
> possibility of that. Windows ME was a dead end product at the end of
> the Win 9x product line. Windows Vista is the ongoing development of
> the NT desktop operating lineage from Windows NT via Windows 2000 and
> Windows XP to where we are today and onward to Windows 7 and future
> releases. All effectively built on generational models of the kernel
> (with some backports and cross development from the server team) and
> ongoing security tightening and innovation. 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.
> So no, your Windows Vista will not end up like ME.

I skipped WinMe back then. I think others could skip Vi$ta as well.

--
@~@ Might, Courage, Vision, SINCERITY.
/ v \ Simplicity is Beauty! May the Force and Farce be with you!
/( _ )\ (Xubuntu 8.04.1) Linux 2.6.26.6
^ ^ 10:34:01 up 3 days 19:17 3 users load average: 2.57 2.70 2.51
???! ???! ???! ???! ???! ???! ????? (CSSA):
http://www.swd.gov.hk/tc/index/site_pubsvc/page_socsecu/sub_addressesa

 

[Jimmy Brush]

Can you be more specific as to what you did? You removed the administrator
account from where - permission or owner? Which folder(s), did you create
them or are they system folders?

"Man-wai Chang ToDie (33.6k)" <toylet.toylet@gmail.com> wrote in message
news:uI5UudzLJHA.4600@TK2MSFTNGP06.phx.gbl...
>> I STRONGLY CAUTION you to not change the owner of files created in
>> another Windows installation. This could really muck things up.
>
> Too late. I did it, in that I removed the Administrator accounts from that
> folder. And it seems that it's quite hard to undo the damage. ANd that's
> why I asked, in that I wanna undo the damage.
>
> --
> @~@ Might, Courage, Vision, SINCERITY.
> / v \ Simplicity is Beauty! May the Force and Farce be with you!
> /( _ )\ (Xubuntu 8.04.1) Linux 2.6.26.6
> ^ ^ 10:31:02 up 3 days 19:14 3 users load average: 3.02 2.82 2.51
> ???! ???! ???! ???! ???! ???! ????? (CSSA):
> http://www.swd.gov.hk/tc/index/site_pubsvc/page_socsecu/sub_addressesa

 

[Man-wai Chang ToDie (33.6k)]

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.

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.

That's why I wanna add XP's Admin into access list of folder X under Vi$ta.

> Can you be more specific as to what you did? You removed the
> administrator account from where - permission or owner? Which folder(s),
> did you create them or are they system folders?


--
@~@ Might, Courage, Vision, SINCERITY.
/ v \ Simplicity is Beauty! May the Force and Farce be with you!
/( _ )\ (Xubuntu 8.04.1) Linux 2.6.26.6
^ ^ 11:29:01 up 3 days 20:12 2 users load average: 10.14 9.91 9.47
ä¸å€Ÿè²¸! ä¸è©é¨™! ä¸æ´äº¤! ä¸æ‰“交! ä¸æ‰“劫! ä¸è‡ªæ®º! è«‹è€ƒæ…®ç¶œæ´ (CSSA):
http://www.swd.gov.hk/tc/index/site_pubsvc/page_socsecu/sub_addressesa

 

[FromTheRafters]

"Man-wai Chang ToDie (33.6k)" <toylet.toylet@gmail.com> wrote in message
news:%235UxUA0LJHA.5660@TK2MSFTNGP03.phx.gbl...
> 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.

 

[Jimmy Brush]

If you did exactly what you said you did, you would not be able to access
the folder in Vista either, since no explicit permissions were defined.

In any case, one solution is to grant the Administrator group full control
in Vista, boot into XP and grant the XP user the desired permission, then
remove the administrator group permission if you don't want it to be there.

You should end up with at least two permissions on the file: One granting
your XP user permission, and another granting your Vista user permission.

When you look at the acl editor, you will see a username identified for one
of the permissions (the user account that exists in the running Windows
installation) and, for the other permission, an SID that represents the user
in the offline Windows installation.

- JB


"Man-wai Chang ToDie (33.6k)" <toylet.toylet@gmail.com> wrote in message
news:%235UxUA0LJHA.5660@TK2MSFTNGP03.phx.gbl...
> 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.
>
> 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.
>
> That's why I wanna add XP's Admin into access list of folder X under
> Vi$ta.
>
>> Can you be more specific as to what you did? You removed the
>> administrator account from where - permission or owner? Which folder(s),
>> did you create them or are they system folders?
>
>
> --
> @~@ Might, Courage, Vision, SINCERITY.
> / v \ Simplicity is Beauty! May the Force and Farce be with you!
> /( _ )\ (Xubuntu 8.04.1) Linux 2.6.26.6
> ^ ^ 11:29:01 up 3 days 20:12 2 users load average: 10.14 9.91 9.47
> ä¸å€Ÿè²¸! ä¸è©é¨™! ä¸æ´äº¤! ä¸æ‰“交! ä¸æ‰“劫! ä¸è‡ªæ®º! è«‹è€ƒæ…®ç¶œæ´ (CSSA):
> http://www.swd.gov.hk/tc/index/site_pubsvc/page_socsecu/sub_addressesa

 

[Jimmy Brush]

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@nomail.afraid.org> wrote in message
news:u3YSsJ9LJHA.276@TK2MSFTNGP02.phx.gbl...
>
> "Man-wai Chang ToDie (33.6k)" <toylet.toylet@gmail.com> wrote in message
> news:%235UxUA0LJHA.5660@TK2MSFTNGP03.phx.gbl...
>> 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.
>

 

[Jimmy Brush]

> (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

 

[FromTheRafters]

Thanks for your answer Jimmy.

Having read this:

http://www.microsoft.com/technet/pr...rv/reskit/distrib/dsce_ctl_gstb.mspx?mfr=true

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

"Jimmy Brush" <jb@mvps.org> wrote in message
news:eSHYjY%23LJHA.4772@TK2MSFTNGP06.phx.gbl...
> 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@nomail.afraid.org> wrote in message
> news:u3YSsJ9LJHA.276@TK2MSFTNGP02.phx.gbl...
>>
>> "Man-wai Chang ToDie (33.6k)" <toylet.toylet@gmail.com> wrote in message
>> news:%235UxUA0LJHA.5660@TK2MSFTNGP03.phx.gbl...
>>> 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.
>>
>

 

[Jimmy Brush]

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@nomail.afraid.org> wrote in message
news:exUKQk%23LJHA.4772@TK2MSFTNGP03.phx.gbl...
> Thanks for your answer Jimmy.
>
> Having read this:
>
> http://www.microsoft.com/technet/pr...rv/reskit/distrib/dsce_ctl_gstb.mspx?mfr=true
>
> ...it had me wondering how things may have changed re Vista.
>
> "Jimmy Brush" <jb@mvps.org> wrote in message
> news:eSHYjY%23LJHA.4772@TK2MSFTNGP06.phx.gbl...
>> 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@nomail.afraid.org> wrote in message
>> news:u3YSsJ9LJHA.276@TK2MSFTNGP02.phx.gbl...
>>>
>>> "Man-wai Chang ToDie (33.6k)" <toylet.toylet@gmail.com> wrote in message
>>> news:%235UxUA0LJHA.5660@TK2MSFTNGP03.phx.gbl...
>>>> 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.
>>>
>>
>
>

 

[Jimmy Brush]

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@nomail.afraid.org> wrote in message
news:exUKQk%23LJHA.4772@TK2MSFTNGP03.phx.gbl...
> Thanks for your answer Jimmy.
>
> Having read this:
>
> http://www.microsoft.com/technet/pr...rv/reskit/distrib/dsce_ctl_gstb.mspx?mfr=true
>
> ...it had me wondering how things may have changed re Vista.
>
> "Jimmy Brush" <jb@mvps.org> wrote in message
> news:eSHYjY%23LJHA.4772@TK2MSFTNGP06.phx.gbl...
>> 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@nomail.afraid.org> wrote in message
>> news:u3YSsJ9LJHA.276@TK2MSFTNGP02.phx.gbl...
>>>
>>> "Man-wai Chang ToDie (33.6k)" <toylet.toylet@gmail.com> wrote in message
>>> news:%235UxUA0LJHA.5660@TK2MSFTNGP03.phx.gbl...
>>>> 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.
>>>
>>
>
>

 

[Man-wai Chang ToDie (33.6k)]

Man-wai Chang ToDie (33.6k) wrote:
>> I STRONGLY CAUTION you to not change the owner of files created in
>> another Windows installation. This could really muck things up.
>
> Too late. I did it, in that I removed the Administrator accounts from
> that folder. And it seems that it's quite hard to undo the damage. ANd
> that's why I asked, in that I wanna undo the damage.
>

I thought of a simpler solution: copy the folder into a new folder name
as administrator. That new folder should have the default ownership and
permission while in XP. Then I boot back into Vi$ta and add Vi$ta's
corresponding accounts into the security list.

--
@~@ Might, Courage, Vision, SINCERITY.
/ v \ Simplicity is Beauty! May the Force and Farce be with you!
/( _ )\ (Xubuntu 8.04.1) Linux 2.6.26.6
^ ^ 15:17:01 up 2:23 3 users load average: 1.00 1.38 1.44
???! ???! ???! ???! ???! ???! ????? (CSSA):
http://www.swd.gov.hk/tc/index/site_pubsvc/page_socsecu/sub_addressesa

 

[FromTheRafters]

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@mvps.org> wrote in message
news:ee%230Pi%23LJHA.4772@TK2MSFTNGP03.phx.gbl...
>> (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