From: mayayana on
This is getting off into non-orthodoxy, but I
came up with some simple flags that should
work fine for both Reg. keys and folders. They
check the minimum necessities. The SYNCHRONIZE
flag is left out for compatibility.
(SYNCHRONIZE: The returned FileHandle can be
waited on to synchronize with the completion of
an I/O operation. ... I think I can do without that. :)
Other than that, these are the flags that are
common to both Reg and folder permissions.
(For instance, GENERIC_WRITE includes the
ability to write attributes and extended attributes,
but that doesn't seem to be a deciding factor.)

So this is back to treating ACCESS_MASK as a long:

Private Const PERMS_WRITE As Long = FILE_WRITE_DATA Or FILE_APPEND_DATA Or
READ_CONTROL
Private Const PERMS_READ As Long = FILE_READ_DATA Or READ_CONTROL
Private Const PERMS_EXECUTE As Long = FILE_EXECUTE Or FILE_READ_ATTRIBUTES
Or READ_CONTROL
Private Const PERMS_DELETE As Long = STANDARD_RIGHTS_DELETE
Private Const PERMS_ALL As Long = STANDARD_RIGHTS_REQUIRED Or
SPECIFIC_RIGHTS_REQUIRED

Then after the call to GetEffectiveRightsFromAcl
I take the string that the GetPermissions function
returns, which is now "-----" and fill in anything
relevant like so:

If (CurPerms And PERMS_READ) = PERMS_READ Then Mid$(sPerms, 1, 1) = "R"
If (CurPerms And PERMS_WRITE) = PERMS_WRITE Then Mid$(sPerms, 2, 1) = "W"
If (CurPerms And PERMS_EXECUTE) = PERMS_EXECUTE Then Mid$(sPerms, 3, 1) =
"X"
If (CurPerms And PERMS_DELETE) = PERMS_DELETE Then Mid$(sPerms, 4, 1) =
"D"
If (CurPerms And PERMS_ALL) = PERMS_ALL Then Mid$(sPerms, 5, 1) = "A"



From: Nobody on
"mayayana" <mayaXXyana(a)rcXXn.com> wrote in message
news:OtYZn5wMKHA.1268(a)TK2MSFTNGP04.phx.gbl...
> This is getting off into non-orthodoxy, but I
> came up with some simple flags that should
> work fine for both Reg. keys and folders.

The meaning of bits 0 to 15 of ACCESS_MASK structure depends entirely on the
object type. You can't use file flags for registry flags and vice versa, and
there are several "Securable Objects" than these two. What flags to use in
these bits must match the object type. This is why they are called "Specific
rights", because they are specific to specific objects. There is no uniform
settings for these flags.

ACCESS_MASK
http://msdn.microsoft.com/en-us/library/aa374892(VS.85).aspx

Securable Objects(Click on an object to see the specific rights that apply
to it)
http://msdn.microsoft.com/en-us/library/aa379557(VS.85).aspx

Also, when viewing the security tab in Explorer, what you see is a summary
view. You have to click on Advanced button to see the real permissions. The
button's position may suggest that you have to click on a user or group to
see more details, but it's not. It's Advanced view. After you click
Advanced, you also need to double click on a permission entry(Or click the
Edit button below it) to see the full details. There is even Effective
Permissions tab.



From: mayayana on

> The meaning of bits 0 to 15 of ACCESS_MASK structure depends entirely on
the
> object type. You can't use file flags for registry flags and vice versa,
and
> there are several "Securable Objects" than these two. What flags to use in
> these bits must match the object type. This is why they are called
"Specific
> rights", because they are specific to specific objects. There is no
uniform
> settings for these flags.
>

Yes, that's what we've been talking about.
I'm looking at finding flags that work with
both folders and Reg. keys. (Other objects --
printer, service, share, etc. -- are not relevant
to me and I suspect are rarely relevant to
others. In any case, those objects can be
added later by anyone who's interested.)

The meaning of the specific flags is basically
the same but varies by object as appropriate.
For instance, Registry and Folder/File both use
the same two read flags (1/4) and both seem to
use the same two write flags (2/3). Bit 1 allows reading
data with a file, listing files with a folder. An Admin
has bits 1-6 set for Reg. and bits 1-9 set for folders.
Likewise, for read-only permission, bits 1,4,5 are
set for Reg. while bits 1,4,6,8 are set for folders.
(Bit 1 is FILE_READ_DATA. Bit 4 is for reading
extended attributes.)

If you read the earlier posts and try the code
you'll see that we've worked out the generic flags
used for files/folders. Those don't work for the
Registry, but I've worked out what flags are set
for read-only and full Registry access, as opposed
to read-only and full file/folder access. So the
whole point of my last post was to suggest new
constants that represent definitive flags common
to both objects.


From: Eduardo on
mayayana escribi�:
>> [...]

Based on what I see in the permissions screen of the folders:
right click on the folder, properties, security (tab), advanced (button
at bottom), efective rigths (tab), select (button in the middle),
advanced (button at bottom), search now(button in the middle), then
select the user or user group, OK, OK.

Based on this, I think that my original code is returning the same (my
username has all the righs in a folder unders Program files).
The problem is, that for the current user it returns the rights of what
he can do when running elevated, not what he can do as normal user (this
is my guess).
So, we should rather check the permissions for "Users" and not for the
current user.
I see that the permissions for "Users" match what I can actually do
without running elevated.

What do you think?
From: mayayana on

> Based on what I see in the permissions screen of the folders:
> right click on the folder, properties, security (tab), advanced (button
> at bottom), efective rigths (tab), select (button in the middle),
> advanced (button at bottom), search now(button in the middle), then
> select the user or user group, OK, OK.
>
> Based on this, I think that my original code is returning the same (my
> username has all the righs in a folder unders Program files).
> The problem is, that for the current user it returns the rights of what
> he can do when running elevated, not what he can do as normal user (this
> is my guess).
> So, we should rather check the permissions for "Users" and not for the
> current user.
> I see that the permissions for "Users" match what I can actually do
> without running elevated.
>
> What do you think?

Yes, that's what I'm finding, too. Though
all of this UAC stuff is new to me. To the extent
I use XP/Win7 I generally run as full admin.
with all restrictions disabled.

What I found in my Win7 test, when I had
UAC set low, was that things worked as expected.
But when I set it high (still as admin) things
fail silently. (And I guess Win7 high UAC is the
same as Vista?)

But isn't that the way it's supposed to work?
Don't you need to request admin status with
a manifest in order to have someone see an
elevation prompt? In other words, with Vista/7
Admin is normally not Admin in the first place.
That's a tricky issue, but I figure that it's for
people to work out on their own.

Checking Users permissions doesn't seem to be
of much value. They almost always have the same
read-only permission. If you check the actual
permissions of the CU and then an operation fails,
at least you can know what's going on and give them
some feedback.

What are you trying to do that you need them to be
able to delete files? I was just aiming to set my own
settings file, in a prgoram folder, so that anyone can
write to it. And likewise with my Registry key. I'll
have to do some tests to see whether that's working.



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