Why won't Vista let apps create new folders?

[JeffG]

I have had two similar problems on my system.

1. An application running in one of my user folders has several folders
below the folder it runs in. One of these folders is named 'data'. It needed
to create a file in data\global. This failed until I created the global
folder manually.

2. I have Apache+MySQL+PHP running on my system. PHP was unable to create
the folder 'session' in my AppData\Local\Temp\php folder. Again, if I created
the session folder manually, PHP was then able to create session files in
that folder.

What is happening here? Please help.

 

[Paul Montgumdrop]

I have had two similar problems on my system.

1. An application running in one of my user folders has several folders
below the folder it runs in. One of these folders is named 'data'. It needed
to create a file in data\global. This failed until I created the global
folder manually.

I would assume when you did it manually as user/administrator it saw you
as the owner of the folder.

As opposed to you being a user assessing the folder and the folder was
created by other means, like the folder was created without you doing it
manually, it viewed you as not being owner of the folder, and you would
have had to have taken ownership of the folder as user to fix the
problem of permissions.

2. I have Apache+MySQL+PHP running on my system. PHP was unable to create
the folder 'session' in my AppData\Local\Temp\php folder. Again, if I created
the session folder manually, PHP was then able to create session files in
that folder.

See above.

What is happening here? Please help.

I also think you should do the test that's being explained in the thread
"cannot change Program Files to full control" to see other permission
conflict for the user/admin on Vista.

 

[JeffG]

I would assume when you did it manually as user/administrator it saw you
as the owner of the folder.

As opposed to you being a user assessing the folder and the folder was
created by other means, like the folder was created without you doing it
manually, it viewed you as not being owner of the folder, and you would
have had to have taken ownership of the folder as user to fix the
problem of permissions.

Did you mean accessing? In any case, I would have thought I would be the
owner of the folder however it was created.

This doesn't answer my question: why can't a program run by me in my own
area create another folder beneath the one it's running in? It just doesn't
make sense.

 

[Paul Montgumdrop]

Did you mean accessing? In any case, I would have thought I would be the
owner of the folder however it was created.

No, you are not owner of the folder however it was created.
TrustedInstaller could be the owner on some folders in some cases. It's
not Administrators group or even your individual user account that is
owner of the folder. Or it could be some other User group that is owner
that your individual user account is not a part of the group.

This doesn't answer my question: why can't a program run by me in my own
area create another folder beneath the one it's running in? It just doesn't
make sense.

I suggest that you goto the Security tab for the folders in question, to
the Advanced button, and to the Owner tab and see who is the owner of
the folder, because apparently, it's not you as a user as a user logging
into system with that user-id as user/admin or even Administrators Group.

If the Advanced button is not active when you go to the Security tab,
then use the built-in Administrator account that is an account that has
full admin rights that will enable the Advance button.

<http://www.howtogeek.com/howto/wind...idden-administrator-account-on-windows-vista/>

You should set the ownership to a user group that has full rights access.

 

[JeffG]

Well, here's the permissions tab for the folder in question:
http:/www.enborne.f2s.com/_misc/permissions.jpg

And here is the owner tab for the same folder:
http:/www.enborne.f2s.com/_misc/owner.jpg

Looks like I am the owner and have full permission

In the Effective permissions tab, user Jeff has all boxes checked.

Still confused...

 

[FromTheRafters]

Is your program using RunAsInvoker?

 

[Paul Montgumdrop]

Well, here's the permissions tab for the folder in question:
http:/www.enborne.f2s.com/_misc/permissions.jpg

And here is the owner tab for the same folder:
http:/www.enborne.f2s.com/_misc/owner.jpg

Looks like I am the owner and have full permission

In the Effective permissions tab, user Jeff has all boxes checked.

Still confused...

No, it should be Jeff(machine-name\jeff) who is the user of the
computer, just like Users(machine-name\users) or
Administrators(machine-name\administrators) are users of the machine.

If you add your user account the one you use to login to the computer as
a new user account to the folder (do the checkname) on the ADD or goto
<C> and added it there giving that account full rights, then that is the
account you should be using and NOT this Jeff/desktop thing. What is
this jeff/desktop thing about, because I sure don't know what that is
about? How in the heck did that get there?

Or you change the ownership to the Administrators Group account, because
your login user account if that is user/admin account is part of the
Administrators group.

One can lead a horse to the water, but one cannot make the horse drink.

Here is a *test* I want you to do. You'll find it at "cannot change
Program Files to full control" thread in this NG, do the *test*. Maybe
you won't be so confused. <smile>

 

[Paul Montgumdrop]

Is your program using RunAsInvoker?

I believe when a program is running on a machine under the context of a
logged in user account, it using the machine-name\user or one of the
machine-name\user group accounts.

He is trying to use Jeff\desktop or something has set the owner to be
Jeff/desktop, when it should be Jeff(machine-name\Jeff) as the owner
with Jeff(machine-name\Jeff) having it's permissions set to full rights.
Or if his Jeff account is user/admin on the machine, the Administrators
group should be the owner of the folder.

 

[JeffG]

No, it should be Jeff(machine-name\jeff) who is the user of the
computer, just like Users(machine-name\users) or
Administrators(machine-name\administrators) are users of the machine.

If you add your user account the one you use to login to the computer as
a new user account to the folder (do the checkname) on the ADD or goto
<C> and added it there giving that account full rights, then that is the
account you should be using and NOT this Jeff/desktop thing. What is
this jeff/desktop thing about, because I sure don't know what that is
about? How in the heck did that get there?

Hah! I know where the confusion comes from! I have two systems - my Desktop
and my Laptop. So I gave them the machine names... Desktop and Laptop

So Desktop *is* the machine name.

One can lead a horse to the water, but one cannot make the horse drink.

Here is a *test* I want you to do. You'll find it at "cannot change
Program Files to full control" thread in this NG, do the *test*. Maybe
you won't be so confused. <smile>

Well I did it, finally. And like the other guy, it went exactly as you
predicted.

A little more about the problem I had (have) where the app wouldn't create
the folder 'global' under 'data'. In fact it is a LUA function which calls
io.open() which in turn calls fopen. The call is effectively
fopen("data/global/filename.dsl", "wb"),
where the sub-folder global does not yet exist. So if fopen itself cannot
create non-existent folders on the fly in a file specification, that is the
real problem. As I said, if I create the global folder manually, the file can
be created in that folder ok.

 

[JeffG]

(Sorry if this is a duplicate, but it seemed like my last posting attempt
failed)

No, it should be Jeff(machine-name\jeff) who is the user of the
computer, just like Users(machine-name\users) or
Administrators(machine-name\administrators) are users of the machine.

If you add your user account the one you use to login to the computer as
a new user account to the folder (do the checkname) on the ADD or goto
<C> and added it there giving that account full rights, then that is the
account you should be using and NOT this Jeff/desktop thing. What is
this jeff/desktop thing about, because I sure don't know what that is
about? How in the heck did that get there?

Hah! I know where the confusion comes from! I have two systems - my Desktop
and my Laptop. So I gave them the machine names... Desktop and Laptop

So Desktop *is* the machine name.

One can lead a horse to the water, but one cannot make the horse drink.

Here is a *test* I want you to do. You'll find it at "cannot change
Program Files to full control" thread in this NG, do the *test*. Maybe
you won't be so confused. <smile>

Well I did it, finally. And like the other guy, it went exactly as you
predicted.

A little more about the problem I had (have) where the app wouldn't create
the folder 'global' under 'data'. In fact it is a LUA function which calls
io.open() which in turn calls fopen. The call is effectively
fopen("data/global/filename.dsl", "wb"),
where the sub-folder global does not yet exist. So if fopen itself cannot
create non-existent folders on the fly in a file specification, that is the
real problem. As I said, if I create the global folder manually, the file can
be created in that folder ok.

 

[Paul Montgumdrop]

(Sorry if this is a duplicate, but it seemed like my last posting attempt
failed)



Hah! I know where the confusion comes from! I have two systems - my Desktop
and my Laptop. So I gave them the machine names... Desktop and Laptop

So Desktop *is* the machine name.


Well I did it, finally. And like the other guy, it went exactly as you
predicted.

A little more about the problem I had (have) where the app wouldn't create
the folder 'global' under 'data'. In fact it is a LUA function which calls
io.open() which in turn calls fopen. The call is effectively
fopen("data/global/filename.dsl", "wb"),
where the sub-folder global does not yet exist. So if fopen itself cannot
create non-existent folders on the fly in a file specification, that is the
real problem. As I said, if I create the global folder manually, the file can
be created in that folder ok.

Then I would think that the program is not using Run As Administrator on
the short-cut pointing to the exe, on the exe itself to escalate its
privileges to perform the task or the program is not set to user the UAC
manifest to have the programs privileges.

You remember now, that an user/admin is NOT an user/admin with full
rights like on XP. A program runs under the context of the logged in
user-account. Your user/admin account the one you got out the box and
any new accounts that you may create that are to be an user/admin
account is not an admin account that has full rights. Those user/admin
accounts have two access tokens assigned to them.

One token of admin with full rights is assigned, and another token is
assigned with standard user rights. It is the standard user token that
is assigned to the user/admin account as default, and user/admin is a
standard user until UAC prompts the user/admin to escalate it's
privileges to the admin full rights token to run the program with those
rights or a task at the moment of escalation, and then the user/admin is
returned back to the standard user token.

If it is a non user/admin account, then the user is asked to give a
user-id/psw to a user/admin account to complete the task. But that also
depends on what rights the user account has in NTFS on folders or files
as well for any type of an account.

Did you see that UAC prompt as user/admin as you went to the Security
tab and asked you to allow or disallow your actions, even as user/admin?

If you have seen that UAC prompt, then that's when you're given that
admin full rights token to complete the task, and you are returned to
the standard user token.

Even if you disable UAC, user/admin on Vista is not an user/admin that
has full rights. The only admin account that has full admin rights is
the hidden built-in Administrator account, that same one you see on XP.

Now, it could be that this program you are talking about doesn't have
the power/privileges to do the task, there is no error trapping in the
section of code to inform the user that the requested task the program
is trying to do didn't happen, it didn't blow-up and it just didn't do
it and kept on executing.

So here is some information in general about security on Vista, and what
you as a software developer must be aware of in developing solutions to
run on Vista.

http://technet.microsoft.com/en-us/library/cc709691.aspx
http://technet.microsoft.com/en-us/magazine/cc138019.aspx
http://www.developer.com/net/net/article.php/3695651
<http://news.softpedia.com/news/Admin-Approval-Mode-in-Windows-Vista-45312.shtml>
<http://channel9.msdn.com/posts/jmaz...s-UAC-What-Privelege-Level-Your-App-Requires/>

 

[JeffG]

Paul, thanks for your patience and detailed responses. I now have enough
information to sort out my problem. Many thanks.