Issue481284
This issue tracker has been migrated to GitHub,
and is currently read-only.
For more information,
see the GitHub FAQs in the Python's Developer Guide.
Created on 2001-11-13 13:34 by rrm1, last changed 2022-04-10 16:04 by admin. This issue is now closed.
Messages (8) | |||
---|---|---|---|
msg7524 - (view) | Author: Ruben Marquez (rrm1) | Date: 2001-11-13 13:34 | |
The following code printes PySID:S-1-0x008014000000 for every file on any machine, independent of the real ower of the file: for f in glob.glob("d:/*.*"): try: o = win32security.GetFileSecurity (f,win32security.OWNER_SECURITY_INFORMATION) s = win32security.SID(o) print str(s), except: print "n/a", print " ",f ---------- Interestingly, def prsid(name): import string print string.rjust(name,20), try: sid,box,what=win32security.LookupAccountName (None,name) print str(sid),box,what except: print "oops" Works well, so it doesn't seem to be a problem with PySIDs. Thanks for your help in resolving this. P.S.: (Discussed in http://groups.google.com/groups? hl=en&th=b808d773d7ba0fee) |
|||
msg7525 - (view) | Author: Tim Peters (tim.peters) * ![]() |
Date: 2001-11-13 16:00 | |
Logged In: YES user_id=31435 Reassigned to MarkH, as this is in the Win32 extensions. |
|||
msg7526 - (view) | Author: Mark Hammond (mhammond) * ![]() |
Date: 2002-03-28 03:37 | |
Logged In: YES user_id=14198 This is not a bug. The SID() function does not take a SECURITY_DESCRIPTOR. The fact it *seems* to is an artifact of a SECURITY_DESCRIPTOR implementing the buffer protocol, and the fact that SID() can be constructed with a buffer assumed to be valid SID bits. Thus, your code is attempting to create a SID from the bits in the SECURITY_DESCRIPTOR. The code should change to: o = win32security.GetFileSecurity(f,win32security.OWNER_SECURITY_INFORMATION) s = o.GetSecurityDescriptorOwner() s is not the SID of the owner of the file. There is also GetSecurityDescriptorGroup(), etc. |
|||
msg7527 - (view) | Author: Nobody/Anonymous (nobody) | Date: 2002-06-23 22:59 | |
Logged In: NO Hi Mark, I've had a read through all of the information that I could on this, and the problem resolution that you've outlined here doesn't seem to be valid. That is, if I use: fileSecurity = win32security.GetFileSecurity ('c:/winnt',win32security.OWNER_SECURITY_INFORMATION) and then watch fileSecurity in a debugger like Komodo, I find that there are only three object methods available, fileSecurity.Initialize() fileSecurity.SetDacl() fileSecuiryt.SetSecurityDescriptorDacl() I haven't yet gotten desperate enough to use a tool that allows the inspection of the contents of RAM to find out what's in the fileSecurity object, but I'm getting close to it... ;-) To be completely explicit, if I use: import win32security fileSecurity = win32security.GetFileSecurity ('c:/winnt',win32security.OWNER_SECURITY_INFORMATION) secInfo = fileSecurity.GetSecurityDescriptorOwner() Python errors and the traceback looks like this: Traceback (most recent call last): File "getfilesecurity.py", line 17, in ? secInfo = fileSecurity.GetSecurityDesc AttributeError: GetSecurityDescriptorOwner I love Python and would dearly like to use this API to do some work... I found a white paper written by someone that talked about the possibility of extending a Python module with SWIG to use the GetNamedSecurityInfo() API, but I don't have a C compiler ATM to knock the code up with :-( Oh, and just as background, basically, I'm writing a class library to allow someone to list each unique NT account that has rights to a file/directory and what those (cumulative) rights are. I already have a basic class that will enumerate individual user accounts in local groups for me, now I just need to extend it to point at groups in ACLs... Please please please assist; Cheers, Darryl Dixon |
|||
msg7528 - (view) | Author: Mark Hammond (mhammond) * ![]() |
Date: 2002-06-23 23:15 | |
Logged In: YES user_id=14198 What OS are you on, and what version of win32all. It works fine for me. >>> import win32security >>> fileSecurity = win32security.GetFileSecurity('f:/windows',win32security.OWNER_SECURITY_INFORMATION) >>> secInfo = fileSecurity.GetSecurityDescriptorOwner() >>> secInfo <PySID object at 0x00D18CD8> >>> |
|||
msg7529 - (view) | Author: Darryl Dixon (esrever_otua) | Date: 2002-06-24 00:21 | |
Logged In: YES user_id=567623 Hi Mark, Thanks for getting back to me and giving me the chance to explore this one. I'm using ActiveState ActivePython 2.1.1 build 212. The Release notes say that this includes your Win32 extensions build 135. I'm on Windows 2000 Professional Service Pack 2, and am logged in as an administrator-level account (so permissions shouldn't be an issue). I had a look at the RAM where the fileSecurity object was referenced at, and first line of memory looks like this: unsigned char data[16] = { 0x01, 0x00, 0x00, 0x00, 0x28, 0xB9, 0x60, 0x1E, 0xD0, 0x94, 0x8A, 0x00, 0x00, 0x00, 0x00, 0x00 }; Dunno if that's really relevant at all, as I haven't yet familiarised myself with how this type of object is structured, but if it's any use to you, great :-) Any other information I can supply or things that I can do for you on this I am happy to go through, I'd love to get this working, Thanks heaps, Darryl Dixon exec("def\040me(list= [97,117,116,111,95,114,101,118,101,114,115,101]):\n\tretstr='' \n\tfor\040i\040in\040range(0,len(list)):\n\t\tretstr+='chr('+str (list.pop())+')+'\n\treturn\040retstr[:-1]\nprint\040eval(me())") |
|||
msg7530 - (view) | Author: Mark Hammond (mhammond) * ![]() |
Date: 2002-06-24 00:25 | |
Logged In: YES user_id=14198 It appears the new functions arrived in win32all-141 and later. You can either try upgrading ActivePython, or downloading Python from python.org and win32all from my starship pages. |
|||
msg7531 - (view) | Author: Darryl Dixon (esrever_otua) | Date: 2002-06-24 00:56 | |
Logged In: YES user_id=567623 Hi Mark, Thanks heaps for the pointer - ActiveState's last distribution of Python 2.1 (2.1.3 build 214) includes your Win32all build 145... And, sure enough, when I dir(fileSecurity) I can now see three new useful methods :-D yah!. I knew Python was the right tool for the job ;-) Just as a side note, I have to take this opportunity (as probably the only one I'll get) to say thanks for your awesome contribution of the win32all libraries - they must surely be responsible for most of the adoption of Python on the Win* platform. Awesome stuff. Cheers, Darryl Dixon |
History | |||
---|---|---|---|
Date | User | Action | Args |
2022-04-10 16:04:38 | admin | set | github: 35519 |
2001-11-13 13:34:36 | rrm1 | create |