Good morning,
I'm trying to verify if a batch is executed with administrator permission.
I found this command to verify:
openfiles >nul 2>&1
if NOT %errorLevel% == 0
...
or net session instead of openfiles.
Everything works if I open command prompt as administrator and return an error if I use normal command prompt.
The problem appears when i try to execute two batch in a single elevated permissions command prompt;
The first batch is executed correctly, the second return permissions error.
what am i doing wrong?
It's not as compact as the method you're using, but another method I've successfully used numerous times in the past is as follows:
IF EXIST %SYSTEMROOT%\SYSTEM32\WDI\LOGFILES GOTO GOTADMIN
[Whatever commands you want to run if not running as admin]
:GOTADMIN
[Whatever commands you want to run if running as admin]
This works because, by default, Windows only allows access to the WDI directory with elevated permissions. Thus, by telling the script to look inside that directory for another directory that is supposed to exist, it can be used to detect whether it's running as admin or not. If yes, it'll see that LOGFILES exists and return True. If no, it won't be allowed access to the WDI files, therefore it won't see that LOGFILES exists and will return False.
Admittedly, this only works if the default security permissions on the WDI directory have not been changed, but from my experience it is highly unlikely these permissions would have been changed in most installations. It also requires that the LOGFILES directory inside of the WDI directory has not been deleted or renamed, but I find this highly unlikely to occur since it is an integral part of the WDI directory's purpose.
I have tested and confirmed this to work on Windows 7, 8, 8.1 and 10. I have not tested it on Vista, but I would assume it works because of how similar Vista is to 7. Obviously there's no benefit in using this method on XP since all command prompts by default are run at maximum elevation on that version of Windows.
Related
I am reading and then modifying some data in a file that is located in the Windows program files folder.
Because of this the file does not have write permissions. So I receive an error when trying to write to it.
When manually giving write permissions to the folder containing the file, the script will work.
Is it possible to modify a folders permissions within a Lua script, or write to a file regardless of it's permissions? Or can this only be done manually from the File Explorer?
This is my current section of code that is re-writing the inputFile:
k=0
updatefile = io.open(inputFile,"w")
for k=1,i do
updatefile:write(modfilecontent[k] .. '\n') --This is where I'm blocked by permissions
end
updatefile:close()
Also if there is a solution possible, and I load this script onto another persons computer that does not have admin privileges would the solution still work?
EDIT:
Piglet's solution will work using the os.execute method to change privileges.
As long as the software, that the plug-in is being used in, is ran as admin the first time the permissions will be set. From then on you no longer need to run as admin.
Below is the code that I needed to add to the beginning of the program, minus the brackets of course
os.execute('icacls "C:\\Program Files\\[software name]\\[folder name]" /grant Everyone:(OI)(CI)F /T')
You could use os.execute to run the appropriate Windows command.
See How to grant permission to users for a directory using command line in Windows?
Alternatively use a library that supports stuff like this. Maybe checkout
https://keplerproject.github.io/luafilesystem/manual.html
Also if there is a solution possible, and I load this script onto
another persons computer that does not have admin privileges would the
solution still work?
As that person wouldn't be able to run Lua as administrator that is very unlikely. That would completly defy the purpose of different user levels.
I am trying to verify permissions of all services running on windows. Though verifying permissions individually is quite painful.
Is there any way of piping the result from windows command net start to icacls, to identify permissions for all services?
for %s in (*.exe) do icacls %s //Ensure this command is executed after navigating into C://Windows/System32 directory
I am trying to develop a simple script that can run a second script as the machine's local administrator. As the first script I am currently trying:
set name=%computername%
runas /noprofile /user:%name%\Administrator "cmd.exe /c %cd%bg2.2.bat"
When I run the script it never seems to run the second script, which is located in the same directory. The second script is only for copying files.
del "C:\Windows\obh_logo.bmp"
copy "%cd%obh_logo.bmp C:\Windows\obh_logo.bmp"
When the first script runs I am prompted for the admin password as expected and once I enter it, a second command prompt seems to flicker on the screen then vanishes. It never appears to run the second script. What seems to be the reason for this not working?
%cd%will probably not point where you think it does, (just tested it, of course the variable gets replaced before the command gets called and does actually point to the first scripts dir, but the problem still persists in the second script)
the runaschanges the working directory for the cmd.exe instance you are starting, probably to C:\Windows\system32.
replace it with %~dp0, which yields the drive and path of the current batch file.
But! Your script will not run the second file elevated, just under the Administrator account, which is not the same. Manual confirmation is always necessary, see here for possible ways to request elevation from within your script.
I now assume the missing rights is the actual problem, add a pause statement in your second script to watch it, or call it with cmd /k so the console doesn't close.
I am working on Windows 7 (logged in as session no.1), my Jenkins CI is running as windows service in session 0.
My problem is.. I want to open an Excel file through Jenkins CI in session 0, but want to display its GUI on session 1.
I know that session 0 is isolated in Windows 7, but is it possible to run a process in session 0 and then output in another session? please help.
Edit:
Took a little trial and error, but this is what finally worked for me (Windows 7 64-bit).
Download PsTools from Microsoft site
We only need psexec.exe, but you can extract everything. Extract to some location accessible by Jenkins, preferably without spaces in the path.
Open elevated command prompt: type cmd into Start's quicksearch, right click cmd.exe, select Run as Administrator.
Type C:\path\to\psexec.exe -accepteula and press enter.
Type C:\path\to\psexec.exe -i 1 cmd and press enter. (If you see a command prompt appear, all is good, close it now)
In Job configuration, configure Execute Windows Batch command step
Write the following:
C:\path\to\psexec.exe -accepteula && C:\path\to\psexec.exe -i 1 cmd /c start C:\PROGRA~2\MICROSO~1\path\to\excel.exe
Where:
C:\path\to is your full path to psexec.exe, unless it is in your %path%
-i 1 is the session ID that you want to launch in.
C:\PROGRA~2\MICROSO~1\path\to is your full path to excel.exe without spaces. Since most Office installations are going to be under paths with spaces, like "Program Files (x86), you have to figure out the short path, or place it somewhere without spaces.
Having excel.exe under %path% and working from regular command line was not enough.
A little explanation for those that care:
psexec needs to install a services first. For that, it needs to be run from elevated command prompt for the first time. This is a one-time installation step.
To make psexec work, you need to accept the EULA prompt. This is done per session/user. So even if you run psexec -accepteula in your command prompt, it doesn't help when Jenkins service (running as Local System in session 0) tries to use it. Therefore, you have to place that into the Jenkins job, along with the command. Technically, it only needs to be there once, and can be removed afterwards, but it definitely doesn't hurt to keep it there.
I've used cmd /k and running this command from my local cmd prompt to debug. This is what made me realize I couldn't find a way to escape the spaces (tried various quoting), so had to resort to short file names. Note that short file names are not required, this is just to escape spaces.
no its not-
plus any UI interactions requires you to run Jenkins as Java web start rather than a service or you can not interact with UI elements.
We are a small office with a Linux appliance server (SAMBA) and Win7HP on the desktops. We have one machine that acts as a "backup server" and backs up the server nightly.
Writing what was supposed to be a quick & dirty addition to the backup script that would loop like this:
a. net use * /d /y
b. net use u: \\ourserver\userNN /u:userNN password
c. run sync util to sync u: to this user's storage space on backup server
d. repeat
If I manually create the above in a batch file, everything works fine. (However, for many reasons the procedure must be automated and tied into our existing backup scripts.)
If a script creates the identical batch file and runs it, the first user is logged-in and syncronized, but all subsequent net use attempts fail.
Similarly, if the script attempts to map the drive through code, this message is received:
Unrecognised network error #183
The above error suggests that the network drive/path is unavailable -- but a net use command typed at the command line using identical parameters is successful.
The "backup server" is a Win7HP box with UAC disabled. When cmd prompt is launched, all windows are preceded by the word: Administrator: -- however, when the script launches a command window to net use the drive, the cmd titlebar lacks that prefix.
Any thoughts / ideas?
In order for users to execute this code properly, they will need to have the proper credentials to do so. Also to automate this task, just use Task Scheduler and it should work fine.