Permissions again
in [Visual Basic]
|
From: mayayana on 11 Sep 2009 14:35 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 11 Sep 2009 16:05 "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 11 Sep 2009 18:10 > 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 11 Sep 2009 18:42 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 11 Sep 2009 18:59
> 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. |