Can any user access the %APPDATA% folder? Or can only administrators read & access that directory? Also, do the permissions to access this directory differ over different Windows platforms from 2k to Windows 7?
You can see the permissions on %APPDATA% by using the icacls tool at the command prompt. Here's what it looks like on my machine:
C:\Users\davidp>icacls %APPDATA%
C:\Users\davidp\AppData\Roaming NT AUTHORITY\SYSTEM:(I)(OI)(CI)(F)
BUILTIN\Administrators:(I)(OI)(CI)(F)
MACHINE09\davidp:(I)(OI)(CI)(F)
Successfully processed 1 files; Failed processing 0 files
What this means is that only I, administrators, and the system itself can see the folder. If you run this on a folder where other users can see it, you'll see something like this:
C:\Users\davidp>icacls c:\
c:\ BUILTIN\Administrators:(F)
BUILTIN\Administrators:(OI)(CI)(IO)(F)
NT AUTHORITY\SYSTEM:(F)
NT AUTHORITY\SYSTEM:(OI)(CI)(IO)(F)
BUILTIN\Users:(OI)(CI)(RX)
NT AUTHORITY\Authenticated Users:(OI)(CI)(IO)(M)
NT AUTHORITY\Authenticated Users:(AD)
Mandatory Label\High Mandatory Level:(OI)(NP)(IO)(NW)
Successfully processed 1 files; Failed processing 0 files
You can see that the BUILTIN\Users group can see the c:\ folder (as you would expect).
EDIT
I'm not sure how far back the %APPDATA% variable itself goes back in Windows history. I recommend checking directly. On older systems the cacls command was the predecessor to icacls. Regardless, in Windows NT-based OSes there has always been a profile area visible only to the user and administrators.
%AppData% is a user-specific path. Yes, any user can access %appdata%, but it will go to a different directory for each user. Only an administrator can read the appdata of another user.
Do the effort of actually going to %appdata% on your machine, and looking at the path it gets converted into. Do you see what I mean?
Related
The problem I have is very persistent.
I have a self-extracting rar file, say files.rar.
This is being uncompressed in C:\Program Files (x86)\CompanyName\XDS\bin
Now this starts a batch file, install.bat, which is in the bin folder.
A 32 bit version of cmd.exe executes this batch file.
So far so good, this all works well.
But: I have to rename one file in the bin folder and delete another. You may wonder, why put a file in there that needs to be deleted? Well, I have a 32 and 64 bit version of a driver. Depending on the target, either one of these must be renamed to NatUSB.dll, while the other must be deleted.
If I run this batch file (simplified):
icacls natusb*.dll /inheritance:r /grant:r everyone:(OI)(CI)F
icacls natusb*.dll /T
rename NatUSB_32_ezusb.dll NatUSB32.dll
del NatUSB_32_winusb.dll
I have the following problems:
I need administrator rights and that is not acceptable for the
purpose of my company
Even then I get "Access is denied" for the
renaming, possibly since there exists already a NatUSB32.dll.
However, even as administrator I can not delete this file: "Access is
denied"
The del NatUSB_32_winusb.dll also gives "Access is denied"
Then I tried to copy the two files to bin2. Reason for this: if I do "icacls bin /T" the list of files I get permission info on is too long, so I hoped to get this info just for a few files. Unfuntunately, I get "Access is denied" (while trying to copy to bin2), even while file permissions for administrator and system are "Full control".
BTW, just icacls natusb*.dll /T does not give any permissions, this only seems to work for entire folders.
When I am in the XSD (parent) folder and do "icacls bin2 /inheritance:r /grant:r everyone:(OI)(CI)F"
Next, I do "icacls bin2 /T"
bin2 Everyone:(OI)(CI)(F)
BUILTIN\Users:(OI)(CI)(F)
I still cant copy the few nat*.dll from bin to bin2.
If I try to set access rights on bin folder (very similar to above), I get "bin: The handle is invalid".
BTW, the permissions on bin are as follows:
bin NT SERVICE\TrustedInstaller:(I)(F)
NT SERVICE\TrustedInstaller:(I)(CI)(IO)(F)
NT AUTHORITY\SYSTEM:(I)(F)
NT AUTHORITY\SYSTEM:(I)(OI)(CI)(IO)(F)
BUILTIN\Administrators:(I)(F)
BUILTIN\Administrators:(I)(OI)(CI)(IO)(F)
BUILTIN\Users:(I)(RX)
BUILTIN\Users:(I)(OI)(CI)(IO)(GR,GE)
CREATOR OWNER:(I)(OI)(CI)(IO)(F)
and as stated before, with icacls I can't change any of this. BTW, the security tab doesn't show duplicate groups or names.
In short: I have problems with renaming, deleting files (must urgent, to solve current problem) and also with copying files from C:\Program Files (x86)\XXX\XDS\bin to XDS\bin2.
To solve the problems, I need to use icacls or another build in command in a script to force the access rights. Setting access rights in the security tab of a folder is not acceptable: it needs to be done from script. Also: we can not install 3rd party software, certainly not if it is large or has a commercial license. A few kB, perhaps 1MB is for a free to use tool may be acceptable if all else fails.
The solution should also not require administrator rights.
This is your main problem:
icacls natusb*.dll /inheritance:r /grant:r everyone:(OI)(CI)F
The (OI)(CI) flags are only valid for directories, not for files. Because the flags are invalid, the permission is ignored. So the net effect of this command is to remove all permissions from the file, implicitly denying access to everyone, including administrators.
If you take out the invalid flags, the command will work as expected:
icacls natusb*.dll /inheritance:r /grant:r everyone:F
However, given your description of the problem, it looks as if you will require admin access, because the permissions on the existing folder are read-only for non-administrators. There's no way around that, unless you can install into a different folder (e.g., in the user's Application Data folder) or change the destination folder permissions in advance.
Note that changing the folder permissions is likely to introduce a security vulnerability.
I can't read a particular file, even though as far as I can tell I have read rights on it. Here is what "Effective Access" shows:
Here is what Get-Acl is giving me.
PS ...> Get-Acl .\HelloWorld.java | Format-List
Path : Microsoft.PowerShell.Core\FileSystem::I:\...\HelloWorld.java
Owner : ...\Admin
Group : G:S-1-5-21-4281937098-1570975092-1098596674-513
Access : ...\Admin Allow FullControl
Audit :
Sddl : O:S-1-5-21-3073128669-2165567304-4059943147-1001G:S-1-5-21-4281937098-1570975092-1098596674-513D:PAI(A;;FA;;;S-1-5-21-3073128669-2165567304-4059943147-1001)
When I try to open it in Notepad, or even just copy it from command-line, I get an error:
I:\...>copy HelloWorld.java C:\HelloWorld.java
Access is denied.
0 file(s) copied.
I:\...>more HelloWorld.java
Cannot access file I:\...\HelloWorld.java
I'm logged in as Admin, and also the cmd.exe shell is elevated (right clicked and did "Run as administrator").
Note that it wasn't originally SDDL_PROTECTED, but I added that (via Windows GUI) in an attempt to make sure that there wasn't something being inherited that was confusing access. Then I added an ACE to give Admin full control. The drive was formerly a system disk for a Win7 machine, but I'm trying to read it on a Win10 machine.
When the protections are OK, 2 other problems can occur
path too long: some apps don't like it (but you get file not found rather than access denied): workaround: mount a drive in a lower level using subst and access from here
file is open in write mode by another program/service.
file is encrypted using windows built-in encryption. In that case, it works OK on the original computer, but when you mount the disk somewhere else, you get "access denied" even if the permissions are OK
The chances are: it is option 3 since you switched computers.
I'm trying to create a script that copies a file to the desktop of a remote user. The two computers would be on the same network in the same domain.
So far I've got a batch script that looks something like:
#echo off
set /p user="Username of remote user: "
set /p hostname="Target computer name: "
xcopy [path to local file] "\\%hostname%\c$\Users\%user%\Desktop\"
The above script would only work for Windows 7. Is there a way to make it so that the script would somehow detect to see if the parent folder exists before copying, then if it does to copy? Or can this be achieved with environment variables?
If I just let the above script run as is and the target computer is using Windows XP, then a new directory tree will be created, which is what I'd like to avoid.
https://support.microsoft.com/kb/65994 would work if I were checking the local system, but I'm trying to see if the remote computer's destination folder exists. I don't see how this article answers that.
Just always use the XP version:
xcopy [path to local file] "\\%hostname%\c$\Documents and Settings\%user%\Desktop\"
It turns out that MS realized this would happen and put in a hidden junction from Documents and Settings to Users. You can't CD to it or DIR in it, but you can still use it for anything else you'd use Users for.
I want to see what resources are available to my application's embedded Lua VM via the os.execute functionality.
echo text > c:\foo.txt
Non-privileged users can't create files on the system's drive root (as well as other system folders). Just one example out of many possible...
You can also try to run regedit.exe. As a regular user, you'll be denied.
I want to delete my git repository (.git folder) created by git on my windows 7 box. It says access denied to .git/refs/header folder.
I open a console with Administrator role, issue command "takeown /F heads /A /R", it still says "ERROR: Access is denied.", neither can i do via GUI security dialog.
Any suggestion?
Regards,
Green
An access denied error may mean the file is in use by another process and, for a GIT repository, that seems more likely than a file permissions issue.
(I'm assuming GIT is like SVN where every file in the repository is created by your own account with standard permissions. If that's not the case then I may be wrong.)
As a first step, run Process Explorer as Administrator and push Ctrl-F to open a window where you can type the filename and see which processes (if any) have that file open.
When I say "run as Administrator":
I don't just mean when logged in as Administrator. Windows 7's UAC means Administrator accounts don't run things with full admin access by default. Right-click procmon.exe and choose the "Run as Administrator" option.
I assume you're already familiar with this from running the command prompt as admin. If you just changed to an admin account, but didn't use "Run as Administrator" on the command prompt, then that could be why the takeown command failed. The command prompt should say "Administrator:" in its window title if it is properly elevated, unless UAC is off entirely.
If one or more processes are listed, confirm the full file path in the list (in case some other file on disk has a similar name).
Close any processes which have the file open. Try to close them normally if you can. As a last resort you can end-task them. If it's a process running as another user/account, it might be a service which you can stop.
(Ensure View->Show Processes for All Users is ticked, then find the process in question via the PID column. If you think it's a service, hover the mouse over it and a tooltip will appear telling you the name(s) of any services it is running.)
If you cannot find any process accessing the file, or closing them all still results in an access denied error, and you are definitely trying the deletion from an elevated command prompt, then you might want to try telling Windows to delete the file the next time it is rebooted. You can use the SysInternals MoveFile tool for that.