Ownership of foreign files - XP vs 7P access issues

I added a new drive with a new 7P install to an existing XP box. Both drives are NTFS. Using F12, the system can be booted to either OS with both drives visible. For lack of terminology, lets say that when booted under XP, the local drive & files are 'local', and the 7P drive & files are 'foreign' to XP. Likewise when booted under 7P, the XP drive and files are 'foreign'. Ideally the foreign drives would appear read only to the booted OS, so that mistakes/malware on one OS could not mess up the other drive. Can this be done?

I Ran into the access denied issue under 7P when trying to copy some files over from XP the drive. Most files copy just fine, but a handful of jpg, pdf, txt and other non-system files get 'access denied'. Under 7P, I tried using a 'regular' unelevated administrator acct, an 'elevated' administrator acct, and an explorer window granted admin access. All get denied for these few files. After reading similar posts, this seems to be a common ownership problem that causes much frustration. I know of a few ways to get the files copied. This post is more about getting a better understanding of what is happening. There may be a great explanation out there I just have not seen.

I have to ask: Is there a way to get a SUPERDUPER-elevated admin acct that would never be denied access (SYSTEM level maybe?), or does ownership always trump permissions under 7P?

The working solutions I am aware of:
1) Under XP, copy the local files to an external (non-NTFS?) drive, which changes file ownership to 'everyone'. Under 7P these can then be copied to the 7P drive without issue.
2) Under 7P, use the 'take ownership' shortcut, which changes ownership by (modifying the ACL?) of the foreign drive/file. Seems like this would not be possible if the foreign drive were read only, and modifying a foreign drive seems like a bad idea leading to problems for that foreign OS. If any writing is needed, it should happen only from the local OS.
3) There is supposed to be a way to grant ownership from XP so a foreign OS can later take ownership. If this can be done without the concern of option #2, it would be preferred. Can it?

So what is the actual difference in these files?
I have an XP folder containing a couple of simple pdfs. Under 7P, I have access to one of these, but the other gets 'access denied'. At some level there is a difference that 7P sees. Looking at the properties for these two files locally under XP shows no differences in permissions or ownership. The difference is there, but XP can't see it/isn't showing it. There is only one User-Admin acct under XP, so what circumstance caused the problem file to be different?
Is there another tool under XP that would show me this difference and allow me to locate all the problem files to better anticipate & deal with them?

For this particular file, I stumbled across another solution:
4) Under XP, make a local copy of the problem file first. Under 7P, this new copy did not have access issues. Maybe this is the general solution to all my problem files, but it would be nice to identify the few files and just deal with those.

Thoughts?

Hi Tns1,

tns1 said:

Ideally the foreign drives would appear read only to the booted OS, so that mistakes/malware on one OS could not mess up the other drive. Can this be done?

Not easily. Access control is handled on a per user/group basis, irrespective of the OS or machine accessing the resource. One way to achieve what you have described would be to create a group on each of the machines, add all the user accounts to the groups, then deny the groups from writing to the foreign drive.

tns1 said:

an explorer window granted admin access.

Not exactly sure what you mean by this. If you just opened explorer.exe by right-clicking and selecting Run as administrator, the resulting Explorer window may not necessarily be granted "admin access".

tns1 said:

After reading similar posts, this seems to be a common ownership permissions problem that causes much frustration.

That was misleading.

It is a misconception that simply giving yourself ownership of a file will give you access to it. This is hardly the case. In fact, in any situation, by taking ownership of an object you will not gain any more access to it than originally possessed.

tns1 said:

Is there a way to get a SUPERDUPER-elevated admin acct that would never be denied access (SYSTEM level maybe?)

No. All administrator accounts under Windows exist with equal rights (for the most part, that is). Not even the SYSTEM "account" is king in it's own territory; it just so happens that SYSTEM is listed as having full access in the Access Control List (ACL) of many files. All user accounts are subject to NTFS permission restrictions equally.

tns1 said:

1) Under XP, copy the local files to an external (non-NTFS?) drive, which changes file ownership to 'everyone'. Under 7P these can then be copied to the 7P drive without issue.

You must be careful when being non-specific. What file system are we talking here? Some file systems do not support permissions (and the concept of ownership for that matter) at all, in which case the files it holds are "owned" by everyone by default.

From my limited testing, if one moves a file from Windows to an NTFS formatted drive, the file's owner will change to that of the user account that conducted the move, not "Everyone".

tns1 said:

2) Under 7P, use the 'take ownership' shortcut, which changes ownership (by modifying the ACL?) of the foreign drive/file.

Nope. It changes the owner by changing the owner. Ownership is stored separately from the ACL. The ACL contains that actual access rules of an object.

And if by "'take ownership' shortcut" you mean registry tweaks like this one, they are not guaranteed to grant you access. They may fail under certain permission configurations involving deny entires.

tns1 said:

Seems like this would not be possible if the foreign drive were read only, and modifying a foreign drive seems like a bad idea leading to problems for that foreign OS.

There are many definitions of read-only, and your statement may or may not be true depending on your definition.

Nothing is a bad idea if you are in control, and know what you are doing.

tns1 said:

3) [Is there] supposed to be a way to grant ownership from XP so a foreign OS can later take ownership.

If the XP machine is using NTFS, you can change the owner of the object through the security tab, as usual. But again, simply changing the owner of a file will not do very much.

tns1 said:

I have an XP folder containing a couple of simple pdfs. [...] Looking at the properties for these two [PDF] files locally under XP shows no differences in permissions or ownership. [...] There is only one User-Admin acct under XP, so what circumstance caused the problem file to be different?

There should be no difference in the security settings of these files between your XP and 7 operating systems. Permissions don't just change themselves.

If I may view the permissions of both PDFs you mention, I may point out to you exactly why you do not have access to one of them.

On your Windows 7 install, open an Elevated Command Prompt and enter the below command twice: once for each of the PDFs you've mentioned.

Code:

icacls "C:\path\to\file.pdf"

Copy and paste the outputted text here.

Quote: Originally Posted by tns1
an explorer window granted admin access.


Not exactly sure what you mean by this. If you just opened explorer.exe by right-clicking and selecting Run as administrator, the resulting Explorer window may not necessarily be granted "admin access".

Yes, exactly this.

Quote: Originally Posted by tns1
1) Under XP, copy the local files to an external (non-NTFS?) drive, which changes file ownership to 'everyone'. Under 7P these can then be copied to the 7P drive without issue.


You must be careful when being non-specific. What file system are we talking here? Some file systems do not support permissions (and the concept of ownership for that matter) at all, in which case the files it holds are "owned" by everyone by default.

A fat32 drive.

Quote: Originally Posted by tns1
2) Under 7P, use the 'take ownership' shortcut, which changes ownership (by modifying the ACL?) of the foreign drive/file.


Nope. It changes the owner by changing the owner. Ownership is stored separately from the ACL. The ACL contains that actual access rules of an object.

And if by "'take ownership' shortcut" you mean registry tweaks like this one, they are not guaranteed to grant you access. They may fail under certain permission configurations involving deny entires.

OK, it modifies the MFT. The point is that a file system created under one OS is being modified by another OS. Even if both of these OSs follow the same file system standard, it seems like a less secure way to go about things. Maybe the NTFS standard and implementation has been done so well on these respective OSs that a take ownership scenario is never going to mess up a foreign drive. The sure way is to grant those rights/ownership from the local OS/owner in a way that requires no writes from the foreign OS. When I say no writes, I mean not one bit hidden or otherwise needs to be modified. Not possible?

On your Windows 7 install, open an Elevated Command Prompt and enter the below command twice: once for each of the PDFs you've mentioned.
Code:
icacls "C:\path\to\file.pdf"
Copy and paste the outputted text here.

The first file below can be accessed, the 2nd cannot. Both were downloaded from commercial websites:

F:\PDownloads\network>icacls "F:\PDownloads\network\New network 2015\E7018_RT-N66U_Manual_V2_high_cd-dvd.pdf"
F:\PDownloads\network\New network 2015\E7018_RT-N66U_Manual_V2_high_cd-dvd.pdf
BUILTIN\AdministratorsI)(F)
NT AUTHORITY\SYSTEMI)(F)
No mapping between account names and security IDs was done.
(I)(F)
BUILTIN\UsersI)(RX)
Successfully processed 1 files; Failed processing 0 files

F:\PDownloads\network>icacls "F:\PDownloads\network\New network 2015\GS108E_IG_PE_17Dec10.pdf"
F:\PDownloads\network\New network 2015\GS108E_IG_PE_17Dec10.pdf: Access is denied.
Successfully processed 0 files; Failed processing 1 files

tns1 said:

A fat32 drive.

The FAT32 file system does not support permissions, or the concept of ownership for that matter. So moving a file onto such will not change the file's owner to ‘Everyone’.

tns1 said:

OK, it modifies the MFT. The point is that a file system created under one OS is being modified by another OS. Even if both of these OSs follow the same file system standard, it seems like a less secure way to go about things. Maybe the NTFS standard and implementation has been done so well on these respective OSs that a take ownership scenario is never going to mess up a foreign drive.

How so? I do not share the insecurity you feel.

Running the Take Ownership shortcut on a foreign drive is only going to mess it up as much as it would be messed up if you did so using the correct OS.

tns1 said:

The sure way is to grant those rights/ownership from the local OS/owner in a way that requires no writes from the foreign OS. When I say no writes, I mean not one bit hidden or otherwise needs to be modified. Not possible?

I see your intentions. I’m sorry, but you'll always be under the influence of NTFS permissions while in Windows.

F:\PDownloads\network>icacls "F:\PDownloads\network\New network 2015\GS108E_IG_PE_17Dec10.pdf"
F:\PDownloads\network\New network 2015\GS108E_IG_PE_17Dec10.pdf: Access is denied.
Successfully processed 0 files; Failed processing 1 files

That’s no good. I was hoping to avoid having to use Cacls on the XP machine. Unless you can copy the Icacls tool over, repeat the commands on the XP machine, but using Cacls, and post the results here another time.

The FAT32 file system does not support permissions, or the concept of ownership for that matter. So moving a file onto such will not change the file's owner to ‘Everyone’.

When you copy files to a Fat32 drive from XP, you don't see any ownership or security info in the file properties, but when the drive is viewed from 7P, those same files show "Owner: Everyone" in the details tab for every pdf, txt, xls, and probably every non-executable. For some reason zip and exe files don't have that info. My guess is that this is just 7P pointing out there is no ownership.

Running the Take Ownership shortcut on a foreign drive is only going to mess it up as much as it would be messed up if you did so using the correct OS.

Different patch and update levels? Malware? Failing HW? There are lots of reasons a foreign chunk of code might not handle your data properly.



cacls output for the same two files:
C:\PDownloads\network\New network 2015>cacls "E7018_RT-N66U_Manual_V2_high_cd-dvd.pdf"
C:\PDownloads\network\New network 2015\E7018_RT-N66U_Manual_V2_high_cd-dvd.pdf BUILTIN\Administrators:F
NT AUTHORITY\SYSTEM:F
XPS630\T:F
BUILTIN\Users:R


C:\PDownloads\network\New network 2015>cacls "GS108E_IG_PE_17Dec10.pdf"
C:\PDownloads\network\New network 2015\GS108E_IG_PE_17Dec10.pdf NT AUTHORITY\SYSTEM:F
XPS630\T:F


C:\PDownloads\network\New network 2015>

tns1 said:

Running the Take Ownership shortcut on a foreign drive is only going to mess it up as much as it would be messed up if you did so using the correct OS.

Different patch and update levels? Malware? Failing HW? There are lots of reasons a foreign chunk of code might not handle your data properly.

I don't see how running Take Ownership on files located in places other than the boot partition may increase your chances of data loss via malware, failing hard drive, etc.

The 'Take Ownership' shortcut is not built from foreign code. It's a well-defined sequence of commands that are especially designed for Windows.

tns1 said:

cacls output for the same two files:

Code:

C:\PDownloads\network\New network 2015>cacls "E7018_RT-N66U_Manual_V2_high_cd-dvd.pdf"
C:\PDownloads\network\New network 2015\E7018_RT-N66U_Manual_V2_high_cd-dvd.pdf BUILTIN\Administrators:F
                                                                               NT AUTHORITY\SYSTEM:F
                                                                               XPS630\T:F
                                                                               BUILTIN\Users:R


C:\PDownloads\network\New network 2015>cacls "GS108E_IG_PE_17Dec10.pdf"
C:\PDownloads\network\New network 2015\GS108E_IG_PE_17Dec10.pdf NT AUTHORITY\SYSTEM:F
                                                                XPS630\T:F

As you may observe, the permissions for the two PDFs are indeed different.

On PDF 1, “E7018_RT-N66U_Manual_V2_high_cd-dvd.pdf”, the permissions grant full access to members of the Administrators group, SYSTEM, and a user named ’T’ on computer ‘XPS630’. And read-only access is granted to members of the Users group.

On PDF 2, “GS108E_IG_PE_17Dec10.pdf”, full access is granted to SYSTEM, and a user named ’T’ on computer ‘XPS630’.


Using this data from Cacls, here are the resulting permissions in effect when accessing the PDF from the two computers:

Code:

        ╔══════════════════════════╦══════════════╗
        ║            7P            ║      XP      ║
╔═══════╬══════════════════════════╬══════════════╣
║ PDF 1 ║ Read* and Full control** ║ Full control ║
║ PDF 2 ║ No access                ║ Full control ║
╚═══════╩══════════════════════════╩══════════════╝

*Or Read and Execute. The old Cacls tool is unable to distinguish the difference.
**When running as administrator.

I agree with Pyprohly

The concept of taking ownership is not something new that Microsoft is still working the bugs out of. It has been a part of the NT platform since it was introduced in 1993. Since then it has been extensively tested by Microsoft and used by large corporations with a great deal to lose if something were to go wrong.

There is no mechanism in Windows to assign ownership to another OS.

I would rather trust taking ownership than any other method you might think of.

It doesn't matter what OS is used to take ownership, whether it be Windows 2000 or Windows 10, 32 bit or 64 bit, the end result is the same.

Quote: Originally Posted by tns1
If I make a local copy under XP, that copy includes the BUILTIN users-groups and has no access issue. I noted before this is probably the easiest solution, but still looking to understand it.


A copied file doesn’t copy the permissions settings with it. The copy file gains a new set of permissions (inheritance) depending on where you copied the file to.

And using your ‘Take Ownership’ shortcut would be the easiest solution.

Quote: Originally Posted by tns1
Would the missing BUILTINs mentioned be 'authenticated users' or some other on the list?


I don’t quite understand your question. These was nothing missing.

From XP, copying these files to the 7P drive gave them identical properties as viewed under icacls:
BUILTIN\Administrators:(I)(F)
T AUTHORITY\SYSTEM:(I)(F)
BUILTIN\Users:(I)(RX)
NT AUTHORITY\Authenticated Users:(I)(M)

Had I instead first added the BUILTIN entities under XP, and then initiated a copy FROM 7P, would I have achieved the exact results?

Since these files were initially 'copied' to XP (downloaded or transfered from media), using the same acct, are sitting in the same location, and were never post edited, why do they not have the same access properties? WRT modifying access permissions, is a cut & paste different from a copy & paste, or move operation? Only the very last copy I did XP:(XP to 7P) seems to have 'standardized' permissions as per location.

If this is all basic stuff, is there a summary tutorial or set of exercises I could read? Thanks.