is there anybody out there, who can help me to query the rights of a
process using twapi?
I've already got this "easy" way to get to know, what rights are "on"
a file, like this:
set securityDescText [get_security_descriptor_text \
[get_resource_security_descriptor file $fileName] \
-resourcetype file \
];
But ... how to do this for a process?
Thanks for any hint!
Best regards,
Martin
Are you looking for something like below?
% twapi::get_process_info 2348 -privileges
-privileges {{SeChangeNotifyPrivilege SeLoadDriverPrivilege
SeUndockPrivilege SeCreateGlobalPrivilege SeImpersonatePrivilege}
{SeSecurityPrivilege SeBackupPrivilege SeRestorePrivilege
SeSystemtimePrivilege SeShutdownPrivilege SeRemoteShutdownPrivilege
SeTakeOwnershipPrivilege SeDebugPrivilege SeSystemEnvironmentPrivilege
SeSystemProfilePrivilege SeProfileSingleProcessPrivilege
SeIncreaseBasePriorityPrivilege SeCreatePagefilePrivilege
SeIncreaseQuotaPrivilege SeManageVolumePrivilege
SeMachineAccountPrivilege}}
Mark
your suggestion is only one part of my aim to reach.
I want to know, what rights the process has to e.g. create files or
directories in a specific directory.
This can be dependend on the user, who created the process, but can be
dependend too, on Local-Policy-Rules, for the process.
I already experienced, that an application, installed as
Administrator, behaves different to the same application installed as
normal user, but started as Administrator.
So I want to query an existing process, to find out its rights, not
only its privileges.
Is twapi able to do this?
It seems, that I'm not able to combine the right ACL, ACE twapi
commands to get the information I want.
Currently I use:
set secd [get_resource_security_descriptor \
file \
$processPath \
];
set desc [get_security_descriptor_text \
$secd \
-resourcetype process \
];
Thanks in advance for any hint!
Martin Lemburg
Please note that for the general case, it is not only what privileges that
the process has but what Access Control List are on the file(s) and/or
directories. This becomes even more complicated if directory is remotely
mounted and the remote file server is running a different operating system.
I'm not sure that in the general case you can find out if you can create a
file (at a given time) without actually attempting to create it at that time.
--
+--------------------------------+---------------------------------------+
| Gerald W. Lester |
|"The man who fights for his ideals is the man who is alive." - Cervantes|
+------------------------------------------------------------------------+
to be honest, ... it's about old tcl code, that simply tries the
following to determine if a directory is usable for this old tcl code:
1. it opens a file for writing, catching a probably occurring
error, and closes it if succeeded
2. it creates a sub directory
3. it opens a file for writing inside the sub directory (like (1))
4. it deletes the sub directory
Now we have suddenly a customer (the first time), where this test
fails in the installed environment and we have to find out, why our
process is not able to do its job (creating and saving data), while
the user on the command prompt is able to create files, directories,
etc..
That's the reason, why I took a look at twapi!
So it's not only about knowing, that some does not work ... it's more
about trying to find out why it's not working!
Best regards,
Martin Lemburg
If I understand you correctly, you want to know if a process running
under a specific account can access a file or not based on its
security descriptor. TWAPI does not provide a direct command to do
this. You would have to do something along the following lines - get
the resource security descriptor for the file, get the ACE's from the
security descriptor, match your account AS WELL AS any local/domain
groups you belong to against the SID's for each ACE (in order). When a
match is found, check whether it is an ALLOW or DENY ACE.
However, if you can access the file from the DOS prompt running under
the same account, I suspect something else is going on, and the
security descriptor is not the problem.
/Ashok
On Jul 23, 8:03 pm, "MartinLemburg@UGS" <martin.lemburg....@gmx.net>
wrote: