Ownership of foreign files - XP vs 7P access issues

tns1 · Apr 12, 2016

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?

Pyprohly · Apr 13, 2016

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 "[COLOR="red"]C:\path\to\file.pdf[/COLOR]"

Copy and paste the outputted text here.

tns1 · Apr 13, 2016

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\Administrators

I)(F)
NT AUTHORITY\SYSTEM

I)(F)
No mapping between account names and security IDs was done.
(I)(F)
BUILTIN\Users

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

Pyprohly · Apr 13, 2016

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.

tns1 · Apr 14, 2016

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>

Pyprohly · Apr 14, 2016

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.

Click to expand...

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.

tns1 · Apr 14, 2016

Quote: Originally Posted by tns1
Quote:
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.

'Foreign' as in originating from a different install under a different OS and almost certainly NOT running the exact same set of instructions. I am sure everything possible is done to have consistent results on every win platform from XPx32 to W10x64, and if every platform is running fully patched code, on sound HW, on pristine installations, with reliable power, then the only thing you really have to trust is that MS got it right. You see that there is a trust level and a risk even in this fantasy setup. A strict read-only scenario would be largely immune from these risks as well as the much larger real-world risks. If windows-ntfs doesn't support that scenario, I'll just have to live with it.

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

By testing, it looks as though every file that shows BUILTIN\Administrators:F, and BUILTIN\Users:R in the ACLs, has no access problems from 7P. Files that don't show these will deny access. How were these files created without similar ACLs? Is this due to platform or did the creators just edit the ACLs?

Is it enough to add the missing BUILTIN users-groups to those files, or is there more? Under 7P when I look at properties->security->edit->add->advanced->find now, there is no BUILTIN listed.

edit
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. I see now that I can select BUILTIN categories from find now. Would the missing BUILTINs mentioned be 'authenticated users' or some other on the list?

LMiller7 · Apr 14, 2016

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.

Pyprohly · Apr 15, 2016

Thank you LMiller7, that was precisely what I had to say.

tns1 said:
By testing, it looks as though every file that shows BUILTIN\Administrators:F, and BUILTIN\Users:R in the ACLs, has no access problems from 7P.

Your access control to files with only those two permissions on them will be exactly the same on both your operating systems: Read (and maybe Execute) or Full control when running applications as administrator.

tns1 said:
Files that don't show these will deny access.

Just to be clear, things aren’t that simple, and your observation will not hold true for many cases. You can have a file with those mentioned permissions and still not have access to them.

tns1 said:
How were these files created without similar ACLs? Is this due to platform or did the creators just edit the ACLs?

Like the difficulty associated with finding the absolute creation date of a file, it’s difficult to know how certain combinations of permissions find their way on files. One of your PDFs likely has inheritance enabled and the other does not. How this happened, we can only imagine.

If you use the newer Icacls instead, we’d be able to tell which of the permissions are inherited and which are not.

tns1 said:
Is it enough to add the missing BUILTIN users-groups to those files, or is there more?

Yes and no. I can't easily answer this without knowing the exact definition of ‘enough’. Does ‘enough’ mean the same permissions as PDF 1? Read (and Execute) and or Full control (as admin)? If that’s the case then adding those ACEs will most likely be enough. But if you do so you’ll be adding explicit permissions, not addressing the permission inconsistencies, only plugging it.

tns1 said:
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.

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

tns1 said:
Would the missing BUILTINs mentioned be 'authenticated users' or some other on the list?

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

tns1 · Apr 17, 2016

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.

Pyprohly · Apr 19, 2016

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

Yes. As I’ve mentioned, copying a file doesn’t copy the permissions with it. This means if you randomly copy any two files from two distinct locations to the same location, the copies will have identical permissions, regardless of what the original files’ permissions where.

tns1 said:
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?

My answer to the ‘why’ version of this question is no different to the ‘how’. I don’t know, and I don’t have an answer to this.

tns1 said:
WRT modifying access permissions, is a cut & paste different from a copy & paste, or move operation?

If you move a file to a new location, if any, the explicit permissions assigned to the object will follow it to its new location, unlike a copy operation which does not. In this instance, cutting and pasting is similar to a move operation.

tns1 said:
If this is all basic stuff, is there a summary tutorial or set of exercises I could read?

By no means would I consider the topic of NTFS permissions basic, especially when the reality is that many users, even seasoned gurus, do not know how to use the feature, with many favouring tools such as as a substitute for learning all there is to know about Windows’ distinctly involved permissions system. Although in saying that, I should be careful about exaggerating it's difficulty. NTFS permissions is not too difficult of a concept to grasp, and it shouldn't be. But far too many people often like to get the facts wrong, sparing correctness for simplicity, reusing the misleading jingle—“you need to take ownership of that/those file(s) to access them”—which only demonstrates their misunderstanding of how access control is enforced under Windows, and thereafter misleading people to believe that the reason for their access issues is solely based upon ownership.

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

If you wish to learn to properly deal with access denied issues under Windows, erase everything you know about permissions, ownership, etc., and start here. Even better than reading, explore the consequences of certain permission configurations by testing out some different situations on your own, and you will very quickly appreciate the security model Microsoft has chosen for their industry-dominating operating systems.

townsbg · Apr 19, 2016

I wouldn't worry about ownership of a file on either system and in fact I would leave that be. Just because your user is the same name on each system doesn't mean that you will be the owner on the other system, if you change it. The inverse is true actually since all user accounts have a unique identifier which likely differs on each system. As a result if you where to change ownership of a file on one system the other system will report that the owner is unknown hence my recommendation not to change it. Now a way around that would be to change your identifier on one system to match the other however that will break your profile unless you change every registry entry and every system file that references it. The best thing that you can do would be to grant your account access to the files/folders in question on both systems. Now if it where me I would create another partition and store the files on that partition granting yourself access within each system. An alternative would be to have that partition be fat32. That would bypass the permissions issue since fat32 doesn't use ntfs permissions.

Ownership of foreign files - XP vs 7P access issues

New member

My Computer My Computer

At a glance

New member

My Computer My Computer

At a glance

New member

My Computer My Computer

At a glance

New member

My Computer My Computer

At a glance

New member

My Computer My Computer

At a glance

New member

My Computer My Computer

At a glance

New member

My Computer My Computer

At a glance

New member

My Computer My Computer

At a glance

New member

My Computer My Computer

At a glance

New member

My Computer My Computer

At a glance

New member

My Computer My Computer

At a glance

тσωηsвg

My Computers My Computers

At a glance

At a glance

Similar threads

My Computer

My Computer

My Computer

My Computer

My Computer

My Computer

My Computer

My Computer

My Computer

My Computer

My Computer

My Computers