File/folder security in Windows 8: a strange problem

[JR]

Hia folks

My company has been testing Windows 8 at work. We're still running XP,
but we want to slowly upgrade everyone . Since there's no point in
going over 2 upgrades (XP -> 7 -> 8) we decided to "bite the bullet"
and go W8 all the way. But the weird has been cropping up...

Our latest is this:

I'm setting up a PC for a user, call him USERBOB. I used my own user,
ADMINJOE, to fully install and configure it. I also installed a
sofware we use inhouse. And here is where things go weird...

At the end of installing everything with DOMAIN\ADMINJOE, I rebooted
and logged into the PC with DOMAIN\USERBOB; I then altered 2 config
files of our software, but, when tried to save them, I got the message
"acess denied"!! And I can't figure out why!

These are the current permissions

DOMAIN\ADMINJOE is both network and local admin; installed all the
software in the PC
DOMAIN\USERBOB is a normal network user and local admin;

Both the software folder AND the config files have the correct
security settings: full access to local admins. I've also tried
turning USERBOB into a network admin (to make it equal to mine), but
no luck. When I try to copy+paste, or delete, a file in that folder, I
get a message "you must supply administrator permission" before I can
do it... which is odd, since the user IS a local admin...

Any ideas on what may cause this?
---//---

"I have come here to chew bubblegum and kick ass. And I'm all out of bubblegum."
--------------------------
Comparisons of sizes: W40k vs other models
http://www.pbase.com/hammerbolt/compare

[Seth]

"JR" > wrote in message
...
> Hia folks
>
> My company has been testing Windows 8 at work. We're still running XP,
> but we want to slowly upgrade everyone . Since there's no point in
> going over 2 upgrades (XP -> 7 -> 8) we decided to "bite the bullet"
> and go W8 all the way. But the weird has been cropping up...
>
> Our latest is this:
>
> I'm setting up a PC for a user, call him USERBOB. I used my own user,
> ADMINJOE, to fully install and configure it. I also installed a
> sofware we use inhouse. And here is where things go weird...
>
> At the end of installing everything with DOMAIN\ADMINJOE, I rebooted
> and logged into the PC with DOMAIN\USERBOB; I then altered 2 config
> files of our software, but, when tried to save them, I got the message
> "acess denied"!! And I can't figure out why!

How about a specific path to these files? I'm guessing either in \Windows or
\Program Files (or \Program Files (x86)

> These are the current permissions
>
> DOMAIN\ADMINJOE is both network and local admin; installed all the
> software in the PC
> DOMAIN\USERBOB is a normal network user and local admin;
>
> Both the software folder AND the config files have the correct
> security settings: full access to local admins. I've also tried
> turning USERBOB into a network admin (to make it equal to mine), but
> no luck. When I try to copy+paste, or delete, a file in that folder, I
> get a message "you must supply administrator permission" before I can
> do it... which is odd, since the user IS a local admin...

There is a difference between an account having admin level privileges and
and actually executing something as admin. Just because a user is capable
of admin level operations doesn't mean they are running with that level of
rights at all times. Like in Linux (and Unix) just because you are logged
in as "root" doesn't mean you can do system level tasks without first doing
an "su" or "sudo".

The proper answer is to modify the app so that it's "transient" files reside
either in the users profile path (if user specific) or in the hidden folder
structure \ProgramData.

[JR]

>
>How about a specific path to these files? I'm guessing either in \Windows or
>\Program Files (or \Program Files (x86)

The files are in program files\softwarename


>There is a difference between an account having admin level privileges and
>and actually executing something as admin. Just because a user is capable
>of admin level operations doesn't mean they are running with that level of
>rights at all times. Like in Linux (and Unix) just because you are logged
>in as "root" doesn't mean you can do system level tasks without first doing
>an "su" or "sudo".
>
>The proper answer is to modify the app so that it's "transient" files reside
>either in the users profile path (if user specific) or in the hidden folder
>structure \ProgramData.
>

So, if a user is part of the PC's "adminstrators" group, he still
can't alter files in this directory?
---//---

"I have come here to chew bubblegum and kick ass. And I'm all out of bubblegum."
--------------------------
Comparisons of sizes: W40k vs other models
http://www.pbase.com/hammerbolt/compare

[Seth]

"JR" > wrote in message
...
>
>>
>>How about a specific path to these files? I'm guessing either in \Windows
>>or
>>\Program Files (or \Program Files (x86)
>
> The files are in program files\softwarename

As I suspected.

>>There is a difference between an account having admin level privileges and
>>and actually executing something as admin. Just because a user is capable
>>of admin level operations doesn't mean they are running with that level of
>>rights at all times. Like in Linux (and Unix) just because you are logged
>>in as "root" doesn't mean you can do system level tasks without first
>>doing
>>an "su" or "sudo".
>>
>>The proper answer is to modify the app so that it's "transient" files
>>reside
>>either in the users profile path (if user specific) or in the hidden
>>folder
>>structure \ProgramData.
>
> So, if a user is part of the PC's "adminstrators" group, he still
> can't alter files in this directory?

Not unless he\she elevates (the prompt you received). How is the system to
know an action was taken on purpose and not malware?

[JR]

On Mon, 29 Oct 2012 15:43:17 -0400, "Seth"
> wrote:


>Not unless he\she elevates (the prompt you received). How is the system to
>know an action was taken on purpose and not malware?
>
>

So, basically, even if 2 users are local admin, only the user that
actually installed the software (and created the folders/files) can
alter them?
---//---

"I have come here to chew bubblegum and kick ass. And I'm all out of bubblegum."
--------------------------
Comparisons of sizes: W40k vs other models
http://www.pbase.com/hammerbolt/compare

[Seth]

"JR" > wrote in message
...
> On Mon, 29 Oct 2012 15:43:17 -0400, "Seth"
> > wrote:
>
>
>>Not unless he\she elevates (the prompt you received). How is the system
>>to
>>know an action was taken on purpose and not malware?
>
> So, basically, even if 2 users are local admin, only the user that
> actually installed the software (and created the folders/files) can
> alter them?

No, even the person who did the installation has to\should be required to
elevate when altering files in protected locations.

That's why they are protected locations. Again, how is the system to know
an alteration is on purpose and not malware?

[JR]

On Mon, 29 Oct 2012 16:27:19 -0400, "Seth"
> wrote:

>No, even the person who did the installation has to\should be required to
>elevate when altering files in protected locations.
>
>That's why they are protected locations. Again, how is the system to know
>an alteration is on purpose and not malware?
>

True. Then again, it does kinda defeat the whole idea of seting folder
security. What's the point, if even admins can't get it?...
---//---

"I have come here to chew bubblegum and kick ass. And I'm all out of bubblegum."
--------------------------
Comparisons of sizes: W40k vs other models
http://www.pbase.com/hammerbolt/compare

[Seth]

"JR" > wrote in message
...
> On Mon, 29 Oct 2012 16:27:19 -0400, "Seth"
> > wrote:
>
>>No, even the person who did the installation has to\should be required to
>>elevate when altering files in protected locations.
>>
>>That's why they are protected locations. Again, how is the system to know
>>an alteration is on purpose and not malware?
>
> True. Then again, it does kinda defeat the whole idea of seting folder
> security. What's the point, if even admins can't get it?...

Because that's the wrong place to do it. Do it in the right location and
this isn't a problem. Changing the file level permissions doesn't change
that it's part of a "protected path".