[lnkForumImage]
TotalShareware - Download Free Software
Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

microsoft.public.vb.general.discussion

Folder Permissions

Mike Williams

12/11/2011 2:08:00 PM

Although I know the basics about folder permissions and about how things tie
into the users' VirtualStore folders in Vista and Win7 I have never been
able to get my head around how to specify desired security attributes when
creating a new folder, and I am particularly confused about the details of
the SECURITY_ATTRIBUTES structure.

For example, I am trying to create a sub folder in the ProgramData folder
and to give that sub folder full read and write permissions for all users,
so that everyone on the machine can modify any files which that folder
contains without ending up with various different copies of the file in the
various user's VirtualStores. I know there are other locations I could place
such a folder but in this specific case I would prefer to have it in the
ProgramData folder. In order to overcome my current lack of knowledge about
the SECURITY_ATTRIBUTES structure I thought that I could simply use
CreateDirectoryEx and specify as a template a folder which already behaves
in the way I have described. This is the code I am using, and I am running
it "As Admin" (I've omitted the function and the various declarations here
for brevity):

Dim sTemplate As String, sFolder As String
sTemplate = fGetSpecialFolder(CSIDL_COMMON_DOCUMENTS)
sFolder = fGetSpecialFolder(CSIDL_COMMON_APPDATA) & "myFolder02"
CreateDirectoryEx sTemplate, sFolder, ByVal 0&

The folder gets created okay, but it does not behave any differently (in
regards to the requirements I have described) than if I had simply used the
VB MkDir statement. So, the template does not behave in the way I had hoped
it would behave. Also, even if it did work (which it does not!) I would not
be happy with the implied assumption that the Common Documents folder on any
specific machine actually has its normal default security settings. So, it
looks as though I really do need to get my head around the
SECURITY_ATTRIBUTES structure, but at the moment it is just spinning around
(my head I mean, not the structure!).

I would really appreciate it if anyone could help me with this one.

Mike
15 Answers

Mayayana

12/11/2011 3:45:00 PM

0

See here for sample code:

http://www.jsware.net/jsware/v...

There are 3 items there. The "NoSE" PDW code includes
a simple class for setups. It has a function to "free for
all" any folder you create. I use it with my installers now
to create folders under AppPath where I can write TEMP
files, store settings, etc. without anyone getting thwarted
because they don't have permission. If you create the folder
you can set it free.

The NTFS permissions code sample #1 is a more involved
version of the above-detailed code.

The sample #2 is something I wrote when I first had to
deal with Vista/7. It's code that can remove all restrictions
from any folder for all admins. I don't know of any way
to remove all restrictions from *any* folder for all users,
but that's probably not an issue for anyone. What I wanted
at the time was to write a simple applet that could just
remove all restrictions on Vista/7 when I run as Admin.,
and that turned out to be a convoluted but doable task.


--
--
"Mike Williams" <Mike@WhiskyAndCoke.com> wrote in message
news:jc2dda$fpv$1@dont-email.me...
| Although I know the basics about folder permissions and about how things
tie
| into the users' VirtualStore folders in Vista and Win7 I have never been
| able to get my head around how to specify desired security attributes when
| creating a new folder, and I am particularly confused about the details of
| the SECURITY_ATTRIBUTES structure.
|
| For example, I am trying to create a sub folder in the ProgramData folder
| and to give that sub folder full read and write permissions for all users,
| so that everyone on the machine can modify any files which that folder
| contains without ending up with various different copies of the file in
the
| various user's VirtualStores. I know there are other locations I could
place
| such a folder but in this specific case I would prefer to have it in the
| ProgramData folder. In order to overcome my current lack of knowledge
about
| the SECURITY_ATTRIBUTES structure I thought that I could simply use
| CreateDirectoryEx and specify as a template a folder which already behaves
| in the way I have described. This is the code I am using, and I am running
| it "As Admin" (I've omitted the function and the various declarations here
| for brevity):
|
| Dim sTemplate As String, sFolder As String
| sTemplate = fGetSpecialFolder(CSIDL_COMMON_DOCUMENTS)
| sFolder = fGetSpecialFolder(CSIDL_COMMON_APPDATA) & "myFolder02"
| CreateDirectoryEx sTemplate, sFolder, ByVal 0&
|
| The folder gets created okay, but it does not behave any differently (in
| regards to the requirements I have described) than if I had simply used
the
| VB MkDir statement. So, the template does not behave in the way I had
hoped
| it would behave. Also, even if it did work (which it does not!) I would
not
| be happy with the implied assumption that the Common Documents folder on
any
| specific machine actually has its normal default security settings. So, it
| looks as though I really do need to get my head around the
| SECURITY_ATTRIBUTES structure, but at the moment it is just spinning
around
| (my head I mean, not the structure!).
|
| I would really appreciate it if anyone could help me with this one.
|
| Mike
|
|


Mike Williams

12/11/2011 7:08:00 PM

0

"Mayayana" <mayayana@invalid.nospam> wrote in message
news:jc2j34$g0e$1@dont-email.me...
> See here for sample code:
> http://www.jsware.net/jsware/v...

Thanks Mayayana. I had high hopes for that code when I saw its complexity,
but it doesn't seem to work for me, at least not for the purposes I
mentioned. The one I have tried so far is the NTFS permissions code that you
mentioned (the download called ntperms.zip). I wrote some VB code to create
a folder in the ProgramData folder (a folder called MikeTest) and to then
create a small text file in it. I ran this code on my Vista machine in my
own Admin Account using elevated privileges, in the way that a simple
installer might be run, and the folder and the file were created okay.

I then ran the PermsDemo.exe contained in the downloaded project using "Run
as Admin" and I selected "Current User" and I asked it to tell me the
permissions on the ProgramData\MikeTest folder for the current user, which
it reported as 31 - RWDXA without reporting any errors. The same folder
returned lesser permissions when I selected "Users" and asked it to tell me
the permissions for all Users.

I then used PermsDemo.exe in the same manner and I selected "Users" and
asked it to Set full permissions on the ProgramData\MikeTest folder for all
Users, which it appeared to do without error. This was confirmed by
selecting "Users" and asking PermsDemo.exe to tell me the permissions on the
ProgramData\MikeTest folder for "Users", which it now reported as 31 - RWDXA
(the same as it had reported for the Admin User which created the folder).

I then logged on as a standard User and ran some code to load the text file
from the ProgramData\MikeTest folder and change its contents and save it
back. In view of PermsDemo.exe apparently working and apparently setting
full permissions on that folder I expected the original file to change
contents accordingly, however I discovered that everything still worked as
it would have done under normal circumstances, and the original file stayed
the same whereas a new file with the changed contents was created in the
User's VirtualStore folder.

What I was hoping for was to set permissions on a sub folder within the
ProgramData folder such that all Users will be able to both read and write
and change the contents of a file in that sub folder and so that they will
all see exactly the same contents, without any VirtualStore folders or files
being created at all, but that did not happen. So (unless I have missed
something?) it would appear that PermsDemo.exe is merely setting and
reporting permissions on a folder "as the user sees it", and is having no
effect whatsoever on the Vista VirtualStore stuff.

I know that it is possible to set folder security so that it circumvents the
VirtualStore stuff in this respect for a specific sub folder in the
ProgramData folder, but the program in the ntperms.zip file downloaded from
the link you posted does not seem to be able to do it. Have you any idea
whether it is supposed to be able to accomplish this task? Perhaps I have
just done something wrong? Or is there something else that needs to be done
in order to accomplish the task?

Mike

Mike Williams

12/11/2011 8:24:00 PM

0

"Mayayana" <mayayana@invalid.nospam> wrote in message
news:jc2j34$g0e$1@dont-email.me...
> See here for sample code:
>
> http://www.jsware.net/jsware/v...

Actually, further to my previous post, it looks as though the second example
(the ntperms2.zip download) might be the one that accomplishes the job I
want to do. I'll download it now . . . and then I'll open this bottle of
Californian Chardonnay . . . and then . . . well perhaps then I'll just
settle down for the evening and try the code tomorrow. Judging by the
description I suspect it will be easier to digest when I am fully awake . .
.. or perhaps later tonight when I am fully inebriated ;-)

Mike

Mike Williams

12/11/2011 9:14:00 PM

0

"Mike Williams" <Mike@WhiskyAndCoke.com> wrote in message
news:jc33g3$pmm$1@dont-email.me...

> Actually, further to my previous post, it looks as though the second
> example (the ntperms2.zip download) might be the one that accomplishes
> the job I want to do. I'll download it now . . . and then I'll open this
> bottle
> of Californian Chardonnay . . . and then . . . well perhaps then I'll just
> settle down for the evening and try the code tomorrow. Judging by the
> description I suspect it will be easier to digest when I am fully awake .
> . . or perhaps later tonight when I am fully inebriated ;-)

Good grief! This stuff is horrendous! I think I'll go back to my bottle of
Californian Chardonnay and come back to this tomorrow!

Mike

Mayayana

12/12/2011 1:40:00 AM

0

| Good grief! This stuff is horrendous!

And that's the simple version. You might want to
go back to whiskey.

I don't know very much
about virtualization. (Would a write to all users
get virtualized whether one has permission or
not? I don't know. You seem to be saying that
virtualization can be avoided with permissions.)

In my own case I've mainly used the code for
setting up app.path subfolders. Since ProgramData
files will affect all users, and typically contains
settings, I wonder if that might be a special case.

I'll have to look at it again. Permissions is so
complex that I forget the details when I'm not
working with it.


Mayayana

12/12/2011 1:59:00 AM

0

One other quick thought: Did you change permissions
on the file? Also, from what I can find, if a file is once
virtualized then changing permissions won't change that.


Mike Williams

12/12/2011 2:03:00 PM

0

"Mayayana" <mayayana@invalid.nospam> wrote in message
news:jc3n29$4j7$1@dont-email.me...

> One other quick thought: Did you change permissions
> on the file? Also, from what I can find, if a file is once
> virtualized then changing permissions won't change that.

No, I changed just the permissions on the folder. I think I got an error
when I used the code in an attempt to change the file permissions, although
I can't quite remember now, my head was spinning round at the time ;-)

I'll try the second version of the code later today, or perhaps tomorrow. It
looks much more complex than the first version and I need a rest at the
moment :-)

Mike

Mayayana

12/12/2011 2:49:00 PM

0

| > One other quick thought: Did you change permissions
| > on the file? Also, from what I can find, if a file is once
| > virtualized then changing permissions won't change that.
|
| No, I changed just the permissions on the folder. I think I got an error
| when I used the code in an attempt to change the file permissions,
although
| I can't quite remember now, my head was spinning round at the time ;-)
|
| I'll try the second version of the code later today, or perhaps tomorrow.
It
| looks much more complex than the first version and I need a rest at the
| moment :-)
|

I haven't had a chance to try it yet, but I think you
should only need the code from the first version, or
from the Setup1 with noSE package, which is even
simpler.

That code is designed to work on what you've created
yourself. The code in #2 is code for taking ownership so
that one can then set permissions on public folders, system
files, etc. That only seems to work for admins, anyway.
I don't think "lackey users" can take ownership. For admins
it's a bizarre bureaucracy: You don't have permission to
access system files...but you do have power to take ownership
of them....and if you take ownership you can give yorself
permission. :) The #2 code is dsigned to be the programmatic
equivalent of using the command line programs takeown and
cacls together, which is Microsoft's recommended way for
sys admins to get access.

...I can never figure out whether Microsoft
practices "security through obscurity" or "security through
a committee of long-winded obsessive-compulsives". Either
way, the permissions stuff is stunningly overproduced, and
the version I used seems to be the simplest of several
approaches.


Mike Williams

12/12/2011 3:15:00 PM

0

"Mayayana" <mayayana@invalid.nospam> wrote in message
news:jc3lu9$vee$1@dont-email.me...
>> [Mike said] Good grief! This stuff is horrendous!
>
> And that's the simple version. You might want
> to go back to whiskey.

Actually I might do that, now that Christmas is coming, but I'll drink the
stuff without the "e" in it (Scotch!).

> I don't know very much about virtualization.
> (Would a write to all users get virtualized whether
> one has permission or not? I don't know. You
> seem to be saying that virtualization can be avoided
> with permissions.)

Yes, I know it can be avoided because I have tested it on a folder in
CSIDL_COMMON_APPDATA which does have such permissions. I just wish I knew
how to do it! What I mean is that when you install a VB6 app if you create a
data folder for your app in the Common AppData folder (CSIDL_COMMON_APPDATA)
and if you create a file in the folder you have created then the default
behaviour is that any writes to that file when a normal User is running your
app are directed to that specific user's VirtualStore. This means that each
user will "see" a different copy of that file. However, if you grant full
permissions to the folder when you create it then that specific folder and
its contents will not be virtualized and all Users will always see the same
copy of any file that is in it.

I know that there are other places which by default do not virtualize in
this way (the Common Documents folder for example) but in this specific case
I want to do the same with a folder in Common AppData. Also, to be honest,
I've got to the stage where it has made my head spin so much that I am
determined to find out how to do it whether I really want to or not ;-)

Mike

Mike Williams

12/12/2011 3:21:00 PM

0

"Mayayana" <mayayana@invalid.nospam> wrote in message
news:jc5461$mcg$1@dont-email.me...

> I haven't had a chance to try it yet, but I think you
> should only need the code from the first version, or
> from the Setup1 with noSE package, which is even
> simpler.

I'll try that when I get the chance. At the moment it appears that walking
around dozens of huge clothing shops and kitchenware shops (and no computer
shops at all!) is the most important thing in the world, at least according
to my wife ;-)

Mike