From: Eduardo on
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
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
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
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
> 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)


First  |  Prev  |  Next  |  Last
Pages: 1 2 3 4 5 6
Prev: Vb 6.0 MSDN Setup file download.
Next: Run-time error '480'