From: Eduardo on 10 Sep 2009 18:26 Eduardo escribi�: > Eduardo escribi�: >> mayayana escribi�: >>> I've been looking further and found >>> GetEffectiveRightsFromAcl. I'll play around >>> with that and see what I come up with. >> >> OK, I could make this API work. > > But I'm not sure what it's returning when I check a virtualized folder, > because for "C:\Program Files\Internet Explorer" it tells me that I have > write rights, when in fact it's virtualized. > > But unlike a "normal" folder, when I ask for all access rights, it tells > me that I don't have. > > And it returns the same if I run it as admin or not. May be it's because I don't have rights to delete the folder. So... it's telling the right virtualized, not the true rights.
From: mayayana on 10 Sep 2009 18:36 That's interesting. Maybe it's feasible, then, to recognize virtualized folders and override the virtualizing with permissions. I haven't tested that yet. I've just tested on XP. We just crossed in the mail. I posted code of my own a few minutes ago. I'll take a look at yours. > >> > >> OK, I could make this API work. > > > > But I'm not sure what it's returning when I check a virtualized folder, > > because for "C:\Program Files\Internet Explorer" it tells me that I have > > write rights, when in fact it's virtualized. > > > > But unlike a "normal" folder, when I ask for all access rights, it tells > > me that I don't have. > > > > And it returns the same if I run it as admin or not. > > May be it's because I don't have rights to delete the folder. > > So... it's telling the right virtualized, not the true rights.
From: mayayana on 10 Sep 2009 21:42 Are you sure about that code? I don't get MapGenericMask. It seems to be used with other methods of returning permission data, and I don't see how it's coming into play with your code. You use the GENERIC_MAPPING strucutre but your final result seems to be based on the And-ing of the desired access with the ACCESS_MASK returned from GetEffectiveRightsFromAcl. That's even more confusing because, as I detailed in my first post that didn't get through, I'm finding no generic flags set in the ACCESS_MASK in any of my tests. I'm basing my return value on the standard rights flags. I have a complete class now for this but the server apparently won't accept it. However, I am going to try to post the function that goes with what I posted earlier: .. '-- Entity: 1-current user. 2-Administrators. 3-users. '-- (Everyone returns a name here but doesn't seem to work with GetEffectiveRightsFromAcl.) Private Function GetLocalName(Entity As Long) As String Dim LRet As Long, LenName As Long, LenDomName As Long, LType As Long, Pt1 As Long, LSid As Long Dim SName As String, sDomName As String Dim SIA As SID_IDENTIFIER_AUTHORITY On Error Resume Next GetLocalName = "" If (Entity <> 2) And (Entity <> 3) Then ' default to current user. Pt1 = 255 SName = String$(Pt1, 0) LRet = GetUserName(SName, Pt1) If (LRet <> 0) Then GetLocalName = Left$(SName, Pt1 - 1) Exit Function End If If Entity = 2 Then 'admins SIA.Value(5) = SECURITY_NT_AUTHORITY LRet = AllocateAndInitializeSid(SIA, 2, SECURITY_BUILTIN_DOMAIN_RID, DOMAIN_ALIAS_RID_ADMINS, 0, 0, 0, 0, 0, 0, LSid) ElseIf Entity = 3 Then 'users SIA.Value(5) = SECURITY_NT_AUTHORITY LRet = AllocateAndInitializeSid(SIA, 2, SECURITY_BUILTIN_DOMAIN_RID, DOMAIN_ALIAS_RID_USERS, 0, 0, 0, 0, 0, 0, LSid End If If LRet = 1 Then SName = Space$(255) sDomName = Space$(255) LenName = 255 LenDomName = 255 LRet = LookupAccountSid(vbNullString, LSid, SName, LenName, sDomName, LenDomName, LType) If LRet = 1 Then Pt1 = InStr(SName, Chr(0)) If Pt1 > 0 Then SName = Left(SName, (Pt1 - 1)) Pt1 = InStr(SName, "\") If Pt1 > 0 Then SName = Right(SName, (Len(SName) - Pt1)) GetLocalName = SName End If FreeSid ByVal LSid End If End Function
From: Eduardo on 10 Sep 2009 22:20 mayayana escribi�: > My code doesn't seem to be getting through. > I'm trying a repost without comments and > with only the GetPermissions function: > > Private Const ST_DELETE = 1 > Private Const ST_READ = 2 > Private Const ST_WRITE = 8 > Private Const ST_ALL = 31 > > Private Type ACCESS_MASK > SpecRights As Integer > StandardRights As Byte > GenericRights As Byte > End Type I have run your code. It seems to me that the actual rights are a combination of the specific rights and the standard rights. So the need to call to the MapGenericMask function. It's very obscure. For my code I took information from several places, but the page I found more useful is http://support.microsoft.com/kb/639482/it From http://msdn.microsoft.com/en-us/library/aa374892%28VS.85%29.aspx you can see that STANDARD_RIGHTS_READ, STANDARD_RIGHTS_WRITE and STANDARD_RIGHTS_EXECUTE all are defined with the same value, that is READ_CONTROL = 2& That makes no sense, not alone. And what you use to check write access, 8&, is WRITE_OWNER, that I don't have any clue what it means.
From: mayayana on 11 Sep 2009 00:29
> more useful is http://support.microsoft.com/kb/639482/it That seems to be the same as your code, but it doesn't make sense to me. The GENERIC_MASK seems to be a superfluous structure. > > From http://msdn.microsoft.com/en-us/library/aa374892%28VS.85%29.aspx > you can see that STANDARD_RIGHTS_READ, STANDARD_RIGHTS_WRITE and > STANDARD_RIGHTS_EXECUTE all are defined with the same value, that is > READ_CONTROL = 2& > > That makes no sense, not alone. That is weird. It's strange how there seem to be numerous ways of doing this, some quite verbose, and often using an entirely different set of functions. In my older copy of MSDN it doesn't have any such confusing constants. By using the ACCESS_MASK structure that I detailed earlier, the standard rights are returned as a byte. (Specific rights depend on the object. And generic rights always returns 0.) In tests on both XP and Win7, with different users, I consistently get the following: Folders: limited permission returns 18 (18 is READ_CONTROL Or SYNCHRONIZE) Full permission returns 31 (31 is all standard rights bytes set, 16-20) Registry: limited permission returns 2 (2 is READ_CONTROL) Full permission returns 15 (15 is all bytes set except byte 20, SYNCHRONIZE) > > And what you use to check write access, 8&, is WRITE_OWNER, that I don't > have any clue what it means. WRITE_OWNER (byte 19) seems to be basic write access. The two write flags (18 and 19) seem to always go together. And STANDARD_RIGHTS_ALL is equivalent to all 5 bytes (16-20) being set. (1F binary is 00011111) |