File permissons

  • Thread starter Thread starter Brian Morris
  • Start date Start date
B

Brian Morris

Hello,
I need some help with setting the correct permissions on computers in a
domain.

My problem is the if Administrator user logs in and runs an app that creates
a file in C:\MyApp, and then Non-Admin user logs in on the same computer and
tries to access the file that was created the Non-Admin user has no file
permissions.

I've noticed that after the Admin user logs off, the advanced security
option on the file for "Inherit from parent the permission entries that
apply to child objects..." does not get turned on even though in the
advanced options for both C:\ and C:\MyApp folders have a tick in "Inherit
from parent the permission entries that apply to child objects. Include
these with..."

I looked at the permissons on both C:\ and C:\MyApp.
C:\
Administrators - Full Control
Creator Owner - Nothing
EveryOne - Nothing
System - Full Control
Users - Read & Execute but not Modify not Write

C:\MyApp
Non-Admin - Nothing
Administrators - Full Control
Creator Owner - Nothing
Domain Users - everything EXCEPT Full Control
System - Full Control
Domain Users - everything EXCEPT Full Control

I don't know where else to look for the option that would tell a file to
inherit permissions from its folder.

Thanks
Brian
 
Try to give the user or a group the user is in explicit permissions to the
c:\myapp folder with appropriate permissions and make sure that the user is
not in a group that has deny permissions to that folder. --- Steve
 
And this is only happening for new folders/files defined by
that one application?
You said you have correctly diagnosed the problem's cause as
option on the file for "Inherit from parent the permission entries that
apply to child objects..." does not get turned on even though in the
Click to expand...
This setting is under the control of the application creating the
filesystem object, and, this is the settings that blocks inheritance, so
on even though in the advanced options for
both C:\ and C:\MyApp folders have a tick in "Inherit
from parent the permission entries that apply to child objects.
Click to expand...
they are ignored, or rather, blocked.
 
I can't say it does not happen for other apps because I don't know if other
apps do a similar thing, however no other app is giving problems.

When you say "This setting is under the control of the application creating
the" does this mean that I should in my code be able to set the behaviour?
Should this be the case? I would have thought not since it would mean that
I could write an app that would disregard the Windows security (like a virus
or something)
This is an MS access app and so far I can't find such options for the RENAME
filename function.

Thanks
Brian
 
Within the power of the account that is executing, an
application can manipulate the NTFS permissions of
filesystem objects (or registry for that matter).
It is a matter of what the application has been coded
to do. For example, if the file is being created in a
folder that has a grant of Creator Owner Full control,
then no matter what the account is that creates the file
it will be able to manipulate all and any of the security
settings of the file it has created. Similarly, if the account
running the application is the owner of a file or folder then
it can make any changes to that file or folder's NTFS settings.
Whether you have "switches" in the application depends on
whether the application was designed to make them available
to you when running the application.
 
Brian,
Try starting notepad, typing something and saving into the
directory. If the permissions of the new file are not what
you expect, then post for us the results from running at a
cmd prompt
cacls <path of folder>
and then
cacls <full file pathname>
that we might see what is happening.
 
Roger,
I understand what you say about the permissions. My code is not
manipulating the permissions so it should definitely (I think) have to do
with the folder settings

This is what I got...

cacls c:\MyApp
everyone:(01)(CI)F
{I had them (my client) do it over the phone so we're not sure if its a zero
or an O}

cacls c:\MyApp\test.txt
everyone:F

cacls c:\MyApp\Temp.mdb
c:\MyApp\Temp.mdb softcom\brian:F
NT authority\system:F
builtin\adimistrators:F

I hope this tells you something.
Thanks a lot
Brian
 
Hi Brian

It is an OI (two letters) for Object Inherit

So the text file is as one would expect, while the mdb
is totally different.

This looks like the mdb may have first been made in
some other location on the same partition, where the
permissions of the containing folder are
System Full, Administrators Full, Creator Owner Full
and then moved to the MyApp folder

Moving a file within a partition takes the permissions
along with it. Now, the file will eventually receive the
inhertable permissions of the move-to location if this
inheritance is not blocked, but that "eventually" takes a
triggering event for it to happen.

If moving of the mdb is not involved then it would be
something about how Access works (?) so you may
want to ask there.
Given what you posted there is no way a file simply
created in or copied into MyApp should have other than
the permissions like those on test.txt
 
Roger,
Yes you are right, I found that it 1st creates the new file in the
MyDocuments folder and then moves it to the C:\MyApp folder. I'll force it
to work in the C:\MyApp folder and see if that solves the whole problem.

What kind of events trigger "eventually"?

Thanks a lot
Brian
 
The eventually is most often an editing of a security
descriptor down within that upon saving triggers the
repropagation of inheritables.
However, this eventuality would not have impact
here since the mdb is marked to block inheritance.
 
Brian,

an afterthought

If you cannot force it to create in MyApps to begin with,
then making it do the initial create on a different partition,
or making it copy into MyApps instead of moving would
solve your issue.
 
Roger,
We tested it today and it seems to work just fine now. Problem solved (for
good I hope).
Thanks a lot
Brian
 
Brian Morris said:
Roger,
We tested it today and it seems to work just fine now. Problem solved (for
good I hope).
Thanks a lot
Brian
Click to expand...

That is good to hear.
Later,
 
Back
Top