Permissions again
in [Visual Basic]
|
From: Eduardo on 11 Sep 2009 19: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? > > 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. I'm running Vista nornally as it's installed by default. > > 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?) I still didn't install Win7, but that seems logical to me. > > 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. Humm, you are right. My conclusion was too soon. I checked the permissions in a normal folder and "Users" has just read only, and I running as normal user can write/delete, etc on the folder. So... where are the permissions for the CU running not elevated?????????????? > 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. I don't like that approach at all. Whay are we bothering with this permission issue at all if at last we are going to trap errors? And there is virtualization that can fool us thinking that we wrote were we think we wrote, but it's just a trick. Isn't it what we are trying to do, to know if we really can write/delete/etc on a folder (without any faked result)? > > What are you trying to do that you need them to be > able to delete files? Right now I'm not trying to do anything that I need, at least I don't need it now. As I told yesterday, what I needed about permissions is done and working several days ago. I needed to share a folder in the network, so I needed to set permissions for "Everyone". Then, if I have to unshare the folder, I wanted to revoke the permissions. It's also working properly. What I'm trying to do now is what you asked for, to find the permissions for the CU on a folder. > 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. I don't criticize you, everyone decides how to approach these problems, but in my case, at least with the two programs that I had to make "Vista compatible", I decided to do everything to run in the way MS wants now, mostry to avoid future problems. So my programs run without privileges, as standard user. But... in one of them, I needed to share a folder and I can't do that as standard user. So in that case, what I did is to shell the same program with "runas", and send in the commnad line what it has to do. So when it needs to perform that operation, the UAC prompts for user approval, another instance of the program runs as admin, do what it needs to do, and ends (without any GUI). Then the main instance of the program checks whether the operation was succesful or not (checks if the folder is actually shared). Everything is already working, partly thanks to the code you had posted.
From: Eduardo on 11 Sep 2009 22:41 Eduardo escribi�: > The difference is, that for example the bit 16, the flag DELETE, if you > use the ACCESS_MASK, its value is 1 and you have to check it in the > StandardRights, but if you use just a long, its value will be &H1FF correction: &H1FFFF
From: mayayana on 12 Sep 2009 01:06 > I checked the permissions in a normal folder and "Users" has just read > only, and I running as normal user can write/delete, etc on the folder. > > So... where are the permissions for the CU running not > elevated?????????????? > It's a very odd system. I'm finding that everything works as expected on XP. My other test is on Win7 with full UAC. That's quite strange. * A number of locations grant Admin everything but Read rights. (Ex.: user folders in Documents and Settings.) I can't open those folders as Admin. But I can give myself permission if I do that elevated. In that case, though, for some reason, inheriting permissions doesn't work. If I give myself permission to open "Fred's" user folder then I have to also give myself explicit permission if I want to then open his Local Settings subfolder. * I edit C:\documents and settings\desktop.ini as Admin: Access denied, even though I have full permission. I then set full permission for all users on that file, using run as admin for that. Now Admin and a standard user can both edit the file without elevation, even though Admin rights have not changed! * Users can create a file in a folder with limited permissions, and can write to that file. But they can't do so if they didn't create the file. All of this seems as expected to me, even though it's a crazy system. :) If I use run as admin to start my demo program I can give any permissions anywhere, to anyone, as far as I can tell. And once I grant permission to Users, Admins also get it without needing to elevate. The only aberrant behavior I find is that with UAC high (like Vista), under normal conditions without requesting elevation, Admins are similar to common users. To put it another way, under UAC an Admin is a fake admin, whose only notable extra rights are the option *in some cases* to get Admin rights in a particular situation. But the fake Admin is limited to right-click Run As Admin, commandline, and scenarios where Windows shows an elevation prompt. If your software is not asking for Admin rights via manifest then fake Admins will never be given a chance to elevate. As I said before, that's good enough for me. If I get access denied then at least I can know that and inform the person that they need to elevate. Aside from that, it's really up to people themselves to run as real admin, turn off UAC, or deal with the frustrating consequences. > As I told yesterday, what I needed about permissions > is done and working > several days ago. > > What I'm trying to do now is what you asked for, > to find the permissions > for the CU on a folder. > Thanks for the help. What I need is also working. I just need to set permissions on program subfolders and a Registry key during setup. That works fine. (Though I think I'll add a test in my installer to check for failure of that operation.) I was just trying to get a better understanding, write a complete set of functions, and invite feedback. So.... we both have what we need now and no one else seems to be interested. I guess we're done. :)
From: Eduardo on 12 Sep 2009 05:12 mayayana escribi�: > * I edit C:\documents and settings\desktop.ini > as Admin: Access denied, even though I have > full permission. How are you reading the permissions? > But the fake Admin is limited > to right-click Run As Admin, commandline, and scenarios > where Windows shows an elevation prompt. If your > software is not asking for Admin rights via manifest > then fake Admins will never be given a chance to elevate. > > As I said before, that's good enough for me. If > I get access denied then at least I can know that > and inform the person that they need to elevate. You can request to elevate without manifiest: Private Declare Function ShellExecute Lib "shell32.dll" Alias _ "ShellExecuteA" (ByVal hwnd As Long, ByVal lpOperation As _ String, ByVal lpFile As String, ByVal lpParameters As String, _ ByVal lpDirectory As String, ByVal nShowCmd As Long) As Long Private Declare Function IsUserAnAdmin Lib "shell32" () As Long Private Sub Form_Load() If IsUserAnAdmin = 0 Then ShellExecute Me.hwnd, "runas", App.Path & "\" & _ App.EXEName & ".exe", Command, vbNullString, 0 End End If End Sub You also should check the OS version because the API function IsUserAnAdmin is not available in older Windows. Or use this other method: http://vbnet.mvps.org/index.html?code/network/isadministrator.htm Compile and run. The key is the word "runas" in the lpOperation parameter. It request to run as admin. > I was just trying to get a better > understanding, write a complete set of functions, > and invite feedback. So.... we both have what we > need now and no one else seems to be interested. I > guess we're done. :) :)
From: mayayana on 12 Sep 2009 10:13
> > * I edit C:\documents and settings\desktop.ini > > as Admin: Access denied, even though I have > > full permission. > > How are you reading the permissions? > Both ways. (API and property page.) But mainly I was checking the API functionality. So I run my test program, check CU rights (logged in as Admin) for the file, and I get back full standard and full specific rights. (First 9 bytes of specific field set. First 5 bytes of standard field set. I've forgotten what the hex is for that. I've been busy exploring how each byte gets set or doesn't.) So ...I get denied with full rights, then I give everyone full rights, then I'm not denied, even though I still have the same full rights. It's wacky! But it does follow a certain twisted logic: Fake Admin is prevented from having Admin rights, but if permission is set for everyone then Admin rights are no longer required. > > You can request to elevate without manifiest: > Thanks. I wasn't aware of that method. When you mentioned it before I thought you meant that you were shelling from command line. So far I've been avoiding asking for Admin rights. I try to make it so that people will have rights within my program folder, and I can keep my operations there. In some cases people will need Admin rights just to use the program functionality. But that's up to them. > Private Declare Function ShellExecute Lib "shell32.dll" Alias _ > "ShellExecuteA" (ByVal hwnd As Long, ByVal lpOperation As _ > String, ByVal lpFile As String, ByVal lpParameters As String, _ > ByVal lpDirectory As String, ByVal nShowCmd As Long) As Long > > Private Declare Function IsUserAnAdmin Lib "shell32" () As Long > > Private Sub Form_Load() > If IsUserAnAdmin = 0 Then > ShellExecute Me.hwnd, "runas", App.Path & "\" & _ > App.EXEName & ".exe", Command, vbNullString, 0 > End > End If > End Sub > > You also should check the OS version because the API function > IsUserAnAdmin is not available in older Windows. > Or use this other method: > http://vbnet.mvps.org/index.html?code/network/isadministrator.htm > > Compile and run. The key is the word "runas" in the lpOperation > parameter. It request to run as admin. > |