Join Forum | Login | Today's Posts | Tutorials | Windows 10 Forum | Windows 8 Forum

 Welcome to Windows 7 Forums. Our forum is dedicated to helping you find support and solutions for any problems regarding your Windows 7 PC be it Dell, HP, Acer, Asus or a custom build. We also provide an extensive Windows 7 tutorial section that covers a wide range of tips and tricks.

# Windows 7: Ownership of foreign files - XP vs 7P access issues

 .
 13 Apr 2016 #2 Pyprohly Windows 10, Windows 8.1 Pro, Windows 7 Professional, OS X El Capitan 667 posts Sydney, NSW Hi Tns1,    Quote: Originally Posted by tns1 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.    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".    Quote: Originally Posted by tns1 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.    Quote: Originally Posted by tns1 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.    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. 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".    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.    Quote: Originally Posted by tns1 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.    Quote: Originally Posted by tns1 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.    Quote: Originally Posted by tns1 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. My System Specs
 .
 13 Apr 2016 #4 Pyprohly Windows 10, Windows 8.1 Pro, Windows 7 Professional, OS X El Capitan 667 posts Sydney, NSW Quote: Originally Posted by tns1 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’.    Quote: Originally Posted by tns1 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.    Quote: Originally Posted by tns1 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. Quote: 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. My System Specs
 14 Apr 2016 #6 Pyprohly Windows 10, Windows 8.1 Pro, Windows 7 Professional, OS X El Capitan 667 posts Sydney, NSW 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.    Quote: Originally Posted by tns1 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. My System Specs
 14 Apr 2016 #8 LMiller7 Windows 7 Pro 64 bit 2,219 posts 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. My System Specs
 17 Apr 2016 #10 tns1 PCs: xp32, 7pro64, 10pro64, Linux 27 posts Quote: 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. My System Specs