What happens to permissions when a file goes to the recycle bin? - windows

I have a problem related to file management done by a service application. My problem is that users are able to move files to the recycle bin for which I've created a hardlink, and once they do this, I loose the ability to list the hardlinks available.
This appears to only happen when the removed hardlink file sits inside the $RECYCLER folder but not on a folder with similar permissions on the same disk.
To replicate my problem assume one has a user account named Service with a suitable password.
On the current user account:
md C:\tmp
echo CONTENTS>C:\tmp\1
fsutil hardlink create C:\tmp\2 C:\tmp\1
That would have created a file named C:\tmp\1 and a hardlink to it named C:\tmp\2.
Now if you runas another terminal with user Service you can:
fsutil hardlink list C:\tmp\1
\tmp\1
\tmp\2
That works fine.
Now if you (as the original user) move the 2 file to the recycle bin, you cannot access the files as Service.
type C:\tmp\1
Access is denied.
fsutil hardlink list C:\tmp\1
Error: Access is denied.
That's because Explorer will have changed the DACL on the file to a restrictive one where only the current user, SYSTEM and an Administrator have access to the file.
If you do a icacls C:\tmp\1 /reset as the original user, now you can access the contents of the file as Service:
type C:\tmp\1
CONTENTS
But if you try to list the hardlinks, it will show you the first link and an access denied error:
fsutil hardlink list C:\tmp\1
\tmp\1
Error: Access is denied.
If you list the hardlinks on the file as the original user, you get to know the recycle bin path of the original file:
fsutil hardlink list C:\tmp\1
\tmp\1
\$Recycle.Bin\S-1-5-21-111111111-2222222222-3333333333-1002\$R1GX1HN
And if you move that file to another (as the original user) folder:
md C:\tmp2
move \$Recycle.Bin\S-1-5-21-111111111-2222222222-3333333333-1002\$R1GX1HN C:\tmp2
Now as Service you can list all the hardlinks:
fsutil hardlink list C:\tmp\1
\tmp\1
\tmp2\$R1GX1HN
Any idea why this may be happening?
Does this have anything to do with Mandatory Integrity Control?

As explained in the comments by #Eryk Sun, the problem is related to the way hardlinks are reported by Win32 API.
It appears that fsutil uses FindFirstFileName and FindNextFileName functions, both of which use NtQueryInformationFile which in turn returns a structure with entries of type FILE_LINK_ENTRY_INFORMATION which have the hardlink name and the parent folder NTFS ID.
The problem manifests itself when the caller does not have permission to open the containing folder to get its name (probably using OpenFileById and GetFinalPathByHandle).

Related

Accessing the Windows Recycle Bin in WSL2

In WSL2, is it possible to access the Windows Recycling Bin? Say for example you move file.txt into the recycling bin in the Windows GUI, could you move to the directory that file.txt is contained in on the WSL terminal? How could this be done?
Officially, no. A special implementation of IShellFolder in shell32 handles the recycle bin when files are moved/deleted in the shell namespace.
Unofficially, each drive contains a hidden $Recycle.Bin folder (Recycler before Vista). Each user has a directory inside there named after their SID where their deleted files are stored.
The deleted files do not retain their original filenames, only their extension. Before Vista, a file named INFO2 stored this information. These days $I... stores the information for the original files renamed to $R...
Look at forensics tools like Rifiuti2 if you need to understand the internal format so you can extract the original name...

Windows can access file, DOS file copy gets Access Denied

I'm trying to set up a set of folders on a Windows NT server 2008 (yes, I know, old) where a user doesn't have access to see the list of files within the folder, but can read a file if they know the full file path.
So I've set up the following AD permissions:
Permissions on the containing folder ("This folder only"):
Traverse folder / execute file
Read attributes
Read extended attributes
Read permissions
Permissions on the files ("Files only"):
Traverse folder / execute file
List folder / read data
Read attributes
Read extended attributes
Read permissions
... and from windows, everything looks great! I can't see inside the folder, but if I know the full path to a file within, I can type it into an address bar and open the file.
But when I run in Command Prompt:
COPY "FullPathToSameFileAsBefore.txt" "C:\someLocalSpot.txt"
... I get:
Access is denied.
0 file(s) copied.
Any ideas? Is there some special access Command Prompt needs to perform the copy that windows doesn't in order to read the file? Any alternatives that will work instead? I can set any of the permissions that are needed, with the caveat that the user cannot see the list of files within the directory.
EDIT with additional info:
So I tried to perform a copy with VBScript using a FileSystemObject. Same error. But using VBScript to read the file with an ADODB binary stream does work.
So it seems to boil down to "You can read this file, but you can't perform a copy." Which seems weird, since if you can read the file, you can certainly copy it (read it, then write the contents someplace else.)

Windows 7 Symbolic Link - Cannot create a file when that file already exists

I'm trying to create a symbolic link between two directories. I have a directory called TestDocs and TestDocs2. I will be doing all my work in TestDocs, but I need it all to be reflected in TestDocs2. So all files that are in TestDocs2 will be replicated in TestDocs, and if I add a file, change a file, etc in TestDocs it should be reflected in TestDocs2.
So I thought it would be as simple as just doing this:
mklink /D TestDocs TestDocs2
But when I do that I get the error:
Cannot create a file when that file already exists
Why am I getting this?
Also, do I have the order of my TestDocs and TestDocs2 wrong in the command?
Thanks for the help, Symbolic Links have always confused me!
The correct usage is:
MKLINK [options] {link} {target}
You're creating a link, so the link is the new link you're about to create.
And the target is the link's target, which is the existing directory.
Here is how that worked for me.
I wanted to relocate my C:\ProgramData\Package Cache to F: partition.
Steps I had to do:
Physically move "C:\ProgramData\Package Cache" to F:. Now I had "F:\ProgramData\Package Cache" and "C:\ProgramData\Package Cache" is gone since I moved it.
In cmd run (all in one line, split here for readability)
mklink /J "C:\ProgramData\Package Cache"
"F:\ProgramData\Package Cache"
Result:
Junction created for C:\ProgramData\Package Cache <<===>>
F:\ProgramData\Package Cache`
I did this for Google Picasa so I could access photographs on more than one machine. It works very well as Picasa is not really a netowrk enabled program.
For me I did the following:
Install Picasa
Run the application. This will create all the necessary database files.
Close the application.
Navigate to the directory where the database is - on Windows 7 it will be created in c:\users\\AppData\Local\Google
There will be two folders Picasa2 and Picasa2Albums
Copy these folders to a network location. In my case I created a folder called o:\PicasaDatabase and copyied these folders into it.
Next rename the original folders to Picasa2.old and Picasa2Albums.old
Run the following commands from an elevated cmd prompt:
mklink /D "c:\Users\\AppData\Local\Google\Picasa2" "o:\PicasaDatabase\Picasa2"
mklink /D "c:\Users\\AppData\Local\Google\Picasa2Albums" "o:\PicasaDatabase\Picasa2Albums"
Two symbolic links will have been created in the source location and they will point to the network drive.
Obviously using symbolic links like this is a workaround for application that are not networkable and only one user can access the database at once.
I had the same issue. You have to make sure the Source folder does not already exist. (if it does , then rename it to something else)
In case of below Backup folder should not exist under MobileSync. Since Apple iTunes looks for Backup folder with that name, just rename the existing folder to something like OriginalBackup to avoid iTunes from finding it. Instead the mklink will synonym Backup to D: folder as below
mklink /J C:\Users\Dell\Apple\MobileSync\Backup D:\Apple\Backup\iPhoneXRBackup
I had this error. Two things I did to fix it.
check I was actually in the directory I thought I was and not another one with a very similar path.
put quotes around the new link name.
First attempt:
mklink /d \shared_files ....\my-app-public\src\shared_files
gave error described.
Second attempt:
mklink /d “.\shared_files” ....\my-app-public\src\shared_files
worked fine.

How to Programatically Replace Files's Permissions with Father's?

I have a folder with permissions already set, in that folder I have some files that should all have the same permissions as the parent folder, the only thing is when these files get replaced by the updater the permissions change.
How can I have the updater replace these files's permissions again with the parent folder's?
Deal with acls sometimes could be annoying, be careful and good luck.
Here is a well-explained article http://msdn.microsoft.com/en-us/magazine/cc163885.aspx
And you could see the icacls and cacls commandline tools.
Use with careful and try to backup before.

How to Access the Undeletable directory/file in windows operating system?

I have doubt in directory undeletable concept. In Windows operation system, we convert a Undeletable file or folder in to deletable by using the command as "cacls FolderName /e /c /g %username%:f". I used the same command to access the "Undeletable folders" (for example Recovery, Documents and Settings etc.,), which is present in the C: drive. It doesn't work. How they create this kind of folders. If any other ways to do this. Kindly clear me. Thanks in advance.
Those folders have the "list folder/read data" permission set to deny for everyone. Deny takes precedence over allow, so it doesn't matter what permissions you give to a user: the deny setting will overrule it. You have to remove that setting first, which probably means you also have to take ownership first. They're owned by SYSTEM.

Resources