ACL To Create and Modify Only New Files?

[Will]

What ACL on NTFS will give a group Read-Only access to files currently in
the folder, but the ability to create and modify and delete new files in the
folder?

I have a badly behaved program that wants to write its TEMP files into its
program installation folder. I would like to avoid the more permission
Modify permission to the users of the application on all files in the folder
including the application's binaries.

One solution appears to be to give files currently in the folder the desired
ACL and then break inheritance. Then give Modify access to the folder and
all children. That isn't my first choice since later updates to the
application will probably install new binaries, and this approach leaves
those installed with Modify access inherited from the folder.

--
Will

 

[Roger Abell [MVP]]

Hi Will,

Long time no see.

I am guessing that the application runs in the context of the
user running it. In that case, try using a grant to CreatorOwner
of Modify on the base folder and below plus a grant to Users
to create the new (that the grant from the CreatorOwner will
then set with modify for the one user). Just follow the model
used at the root of the system partition to allow Users to
create and use new folders.

If the application uses persistent temp files and it is on a
multi-user machine, this of course will not work.
Otherwise there is the laborious approach you mention or
the equally effort intensive approach of setting a deny of
write on the existing files.
To my awareness there is no straightforward way to do this.

Roger

"Will" <westes-usc@noemail.nospam> wrote in message
news:jKOdneQMa87B9DvanZ2dnUVZ_oesnZ2d@giganews.com...
> What ACL on NTFS will give a group Read-Only access to files currently in
> the folder, but the ability to create and modify and delete new files in
> the folder?
>
> I have a badly behaved program that wants to write its TEMP files into its
> program installation folder. I would like to avoid the more permission
> Modify permission to the users of the application on all files in the
> folder including the application's binaries.
>
> One solution appears to be to give files currently in the folder the
> desired ACL and then break inheritance. Then give Modify access to the
> folder and all children. That isn't my first choice since later updates
> to the application will probably install new binaries, and this approach
> leaves those installed with Modify access inherited from the folder.
>
> --
> Will
>

 

[Will]

"Roger Abell [MVP]" <mvpNoSpam@asu.edu> wrote in message
news:%23IqL7XvZIHA.208@TK2MSFTNGP02.phx.gbl...
> Long time no see.
>
> I am guessing that the application runs in the context of the
> user running it. In that case, try using a grant to CreatorOwner
> of Modify on the base folder and below plus a grant to Users
> to create the new (that the grant from the CreatorOwner will
> then set with modify for the one user). Just follow the model
> used at the root of the system partition to allow Users to
> create and use new folders.
>
> If the application uses persistent temp files and it is on a
> multi-user machine, this of course will not work.
> Otherwise there is the laborious approach you mention or
> the equally effort intensive approach of setting a deny of
> write on the existing files.
> To my awareness there is no straightforward way to do this.

Hi Roger. It's not that I didn't have questions in all this time. I guess
I'm just taming my ambitions.

What you suggest makes sense in general, but I don't find an attribute for
just creating new files. The closest attribute is "Create Files / Write
Data". And that sounds suspiciously like a permission to both create new
files but also to modify existing ones. If it is not, then which attribute
would give the ability to modify existing files? It's really a shame that
Microsoft didn't make each part of that a separate attribute.

--
Will



> "Will" <westes-usc@noemail.nospam> wrote in message
> news:jKOdneQMa87B9DvanZ2dnUVZ_oesnZ2d@giganews.com...
>> What ACL on NTFS will give a group Read-Only access to files currently in
>> the folder, but the ability to create and modify and delete new files in
>> the folder?
>>
>> I have a badly behaved program that wants to write its TEMP files into
>> its program installation folder. I would like to avoid the more
>> permission Modify permission to the users of the application on all files
>> in the folder including the application's binaries.
>>
>> One solution appears to be to give files currently in the folder the
>> desired ACL and then break inheritance. Then give Modify access to the
>> folder and all children. That isn't my first choice since later
>> updates to the application will probably install new binaries, and this
>> approach leaves those installed with Modify access inherited from the
>> folder.
>>
>> --
>> Will

 

[Roger Abell [MVP]]

"Will" <westes-usc@noemail.nospam> wrote in message
news:49edneivW94VWjranZ2dnUVZ_o-mnZ2d@giganews.com...
> "Roger Abell [MVP]" <mvpNoSpam@asu.edu> wrote in message
> news:%23IqL7XvZIHA.208@TK2MSFTNGP02.phx.gbl...
>> Long time no see.
>>
>> I am guessing that the application runs in the context of the
>> user running it. In that case, try using a grant to CreatorOwner
>> of Modify on the base folder and below plus a grant to Users
>> to create the new (that the grant from the CreatorOwner will
>> then set with modify for the one user). Just follow the model
>> used at the root of the system partition to allow Users to
>> create and use new folders.
>>
>> If the application uses persistent temp files and it is on a
>> multi-user machine, this of course will not work.
>> Otherwise there is the laborious approach you mention or
>> the equally effort intensive approach of setting a deny of
>> write on the existing files.
>> To my awareness there is no straightforward way to do this.
>
> Hi Roger. It's not that I didn't have questions in all this time. I
> guess I'm just taming my ambitions.
>

Then now you are ready for a welcome to Windows land. <g>
I seem to recall a similar wake-up after my being assigned
(from Unix land) to learn how NT would fit in our shop.

> What you suggest makes sense in general, but I don't find an attribute for
> just creating new files. The closest attribute is "Create Files / Write
> Data". And that sounds suspiciously like a permission to both create new
> files but also to modify existing ones. If it is not, then which
> attribute would give the ability to modify existing files? It's really a
> shame that Microsoft didn't make each part of that a separate attribute.
>

When you look in the advanced view the descriptions for the
individual ACEs have two parts separated by / char. On the
left is what the ACE means applied to a directory, on the right
what it means applied to a file. So, selection of that ACE and
in the dropbox set to This folder only allows only creating new
files in that directory (similarly applied to This folder and subs).

I think this could be seen as artifact of the era when designed
and all bits added up to significant cost, so something like a
double word is all that was allocated for all ACE flags, and
a couple of them for indication of applicability to objects and/or
container objects.

Roger

>
>> "Will" <westes-usc@noemail.nospam> wrote in message
>> news:jKOdneQMa87B9DvanZ2dnUVZ_oesnZ2d@giganews.com...
>>> What ACL on NTFS will give a group Read-Only access to files currently
>>> in the folder, but the ability to create and modify and delete new files
>>> in the folder?
>>>
>>> I have a badly behaved program that wants to write its TEMP files into
>>> its program installation folder. I would like to avoid the more
>>> permission Modify permission to the users of the application on all
>>> files in the folder including the application's binaries.
>>>
>>> One solution appears to be to give files currently in the folder the
>>> desired ACL and then break inheritance. Then give Modify access to the
>>> folder and all children. That isn't my first choice since later
>>> updates to the application will probably install new binaries, and this
>>> approach leaves those installed with Modify access inherited from the
>>> folder.
>>>
>>> --
>>> Will
>
>

 

[Will]

"Roger Abell [MVP]" <mvpNoSpam@asu.edu> wrote in message
news:%23Il4SEAaIHA.6140@TK2MSFTNGP02.phx.gbl...
>> What you suggest makes sense in general, but I don't find an attribute
>> for just creating new files. The closest attribute is "Create Files /
>> Write Data". And that sounds suspiciously like a permission to both
>> create new files but also to modify existing ones. If it is not, then
>> which attribute would give the ability to modify existing files? It's
>> really a shame that Microsoft didn't make each part of that a separate
>> attribute.
>>
>
> When you look in the advanced view the descriptions for the
> individual ACEs have two parts separated by / char. On the
> left is what the ACE means applied to a directory, on the right
> what it means applied to a file. So, selection of that ACE and
> in the dropbox set to This folder only allows only creating new
> files in that directory (similarly applied to This folder and subs).

Aha.... I think I just evolved. Thank you.


> I think this could be seen as artifact of the era when designed
> and all bits added up to significant cost, so something like a
> double word is all that was allocated for all ACE flags, and
> a couple of them for indication of applicability to objects and/or
> container objects.

Regardless of how badly they overloaded the implementation, the user
interface of the Advanced Security Settings dialog for ACLs is fairly awful.
It's way too compressed to easily pull out the explanation you gave just
from usage. And in general the fact that the implementation is overloaded
is not a great reason to overload the user interface in a parallel fashion.

--
Will

 

[Roger Abell [MVP]]

"Will" <westes-usc@noemail.nospam> wrote in message
news:KoKdnaZpcpUdiDTanZ2dnUVZ_rWtnZ2d@giganews.com...
> "Roger Abell [MVP]" <mvpNoSpam@asu.edu> wrote in message
> news:%23Il4SEAaIHA.6140@TK2MSFTNGP02.phx.gbl...
>>> What you suggest makes sense in general, but I don't find an attribute
>>> for just creating new files. The closest attribute is "Create Files /
>>> Write Data". And that sounds suspiciously like a permission to both
>>> create new files but also to modify existing ones. If it is not, then
>>> which attribute would give the ability to modify existing files? It's
>>> really a shame that Microsoft didn't make each part of that a separate
>>> attribute.
>>>
>>
>> When you look in the advanced view the descriptions for the
>> individual ACEs have two parts separated by / char. On the
>> left is what the ACE means applied to a directory, on the right
>> what it means applied to a file. So, selection of that ACE and
>> in the dropbox set to This folder only allows only creating new
>> files in that directory (similarly applied to This folder and subs).
>
> Aha.... I think I just evolved. Thank you.
>
>
>> I think this could be seen as artifact of the era when designed
>> and all bits added up to significant cost, so something like a
>> double word is all that was allocated for all ACE flags, and
>> a couple of them for indication of applicability to objects and/or
>> container objects.
>
> Regardless of how badly they overloaded the implementation, the user
> interface of the Advanced Security Settings dialog for ACLs is fairly
> awful. It's way too compressed to easily pull out the explanation you gave
> just from usage. And in general the fact that the implementation is
> overloaded is not a great reason to overload the user interface in a
> parallel fashion.
>

I was only trying to build insight by sharing context for future
understanding. You probably know me sufficiently well by now
to know I am not interested in making excuses for their design or
implementation shortfalls And yes, I do hear your comment as
I think it took me nearly a year after coming over from Unix to
realize what I explained about the ACEs (but of course, back then
the documentation was very poor and all hidden in the api docs).

Roger

 

[Roger Abell [MVP]]

PS
You might be wondering, if Users only has a grant to create files
at the folder level, then how do they actually write the file. That
is where the grant to Creator Owner comes in.


"Will" <westes-usc@noemail.nospam> wrote in message
news:KoKdnaZpcpUdiDTanZ2dnUVZ_rWtnZ2d@giganews.com...
> "Roger Abell [MVP]" <mvpNoSpam@asu.edu> wrote in message
> news:%23Il4SEAaIHA.6140@TK2MSFTNGP02.phx.gbl...
>>> What you suggest makes sense in general, but I don't find an attribute
>>> for just creating new files. The closest attribute is "Create Files /
>>> Write Data". And that sounds suspiciously like a permission to both
>>> create new files but also to modify existing ones. If it is not, then
>>> which attribute would give the ability to modify existing files? It's
>>> really a shame that Microsoft didn't make each part of that a separate
>>> attribute.
>>>
>>
>> When you look in the advanced view the descriptions for the
>> individual ACEs have two parts separated by / char. On the
>> left is what the ACE means applied to a directory, on the right
>> what it means applied to a file. So, selection of that ACE and
>> in the dropbox set to This folder only allows only creating new
>> files in that directory (similarly applied to This folder and subs).
>
> Aha.... I think I just evolved. Thank you.
>
>
>> I think this could be seen as artifact of the era when designed
>> and all bits added up to significant cost, so something like a
>> double word is all that was allocated for all ACE flags, and
>> a couple of them for indication of applicability to objects and/or
>> container objects.
>
> Regardless of how badly they overloaded the implementation, the user
> interface of the Advanced Security Settings dialog for ACLs is fairly
> awful. It's way too compressed to easily pull out the explanation you gave
> just from usage. And in general the fact that the implementation is
> overloaded is not a great reason to overload the user interface in a
> parallel fashion.
>
> --
> Will
>
>

 

[Will]

"Roger Abell [MVP]" <mvpNoSpam@asu.edu> wrote in message
news:uy0w9dHaIHA.4140@TK2MSFTNGP04.phx.gbl...
> You might be wondering, if Users only has a grant to create files
> at the folder level, then how do they actually write the file. That
> is where the grant to Creator Owner comes in.

Yes, it all came together for me once I understood to apply "create files"
to the folder only.

--
Will


> "Will" <westes-usc@noemail.nospam> wrote in message
> news:KoKdnaZpcpUdiDTanZ2dnUVZ_rWtnZ2d@giganews.com...
>> "Roger Abell [MVP]" <mvpNoSpam@asu.edu> wrote in message
>> news:%23Il4SEAaIHA.6140@TK2MSFTNGP02.phx.gbl...
>>>> What you suggest makes sense in general, but I don't find an attribute
>>>> for just creating new files. The closest attribute is "Create Files /
>>>> Write Data". And that sounds suspiciously like a permission to both
>>>> create new files but also to modify existing ones. If it is not, then
>>>> which attribute would give the ability to modify existing files? It's
>>>> really a shame that Microsoft didn't make each part of that a separate
>>>> attribute.
>>>>
>>>
>>> When you look in the advanced view the descriptions for the
>>> individual ACEs have two parts separated by / char. On the
>>> left is what the ACE means applied to a directory, on the right
>>> what it means applied to a file. So, selection of that ACE and
>>> in the dropbox set to This folder only allows only creating new
>>> files in that directory (similarly applied to This folder and subs).
>>
>> Aha.... I think I just evolved. Thank you.
>>
>>
>>> I think this could be seen as artifact of the era when designed
>>> and all bits added up to significant cost, so something like a
>>> double word is all that was allocated for all ACE flags, and
>>> a couple of them for indication of applicability to objects and/or
>>> container objects.
>>
>> Regardless of how badly they overloaded the implementation, the user
>> interface of the Advanced Security Settings dialog for ACLs is fairly
>> awful. It's way too compressed to easily pull out the explanation you
>> gave just from usage. And in general the fact that the implementation
>> is overloaded is not a great reason to overload the user interface in a
>> parallel fashion.
>>
>> --
>> Will

 

[Roger Abell [MVP]]

"Will" <westes-usc@noemail.nospam> wrote in message
news:ScednXWuFKISpTTanZ2dnUVZ_tqtnZ2d@giganews.com...
> "Roger Abell [MVP]" <mvpNoSpam@asu.edu> wrote in message
> news:uy0w9dHaIHA.4140@TK2MSFTNGP04.phx.gbl...
>> You might be wondering, if Users only has a grant to create files
>> at the folder level, then how do they actually write the file. That
>> is where the grant to Creator Owner comes in.
>
> Yes, it all came together for me once I understood to apply "create files"
> to the folder only.
>
> --
> Will
>

OK, good luck, and please spam the vendor of that app with
a bit of your thoughts about their disregard for the guidance
MS has available for software house about how to write apps
that can be certified as made for Windows By this time
most of the larger app vendors have come around, but the
message still is needed by some.

Roger

>
>> "Will" <westes-usc@noemail.nospam> wrote in message
>> news:KoKdnaZpcpUdiDTanZ2dnUVZ_rWtnZ2d@giganews.com...
>>> "Roger Abell [MVP]" <mvpNoSpam@asu.edu> wrote in message
>>> news:%23Il4SEAaIHA.6140@TK2MSFTNGP02.phx.gbl...
>>>>> What you suggest makes sense in general, but I don't find an attribute
>>>>> for just creating new files. The closest attribute is "Create Files
>>>>> / Write Data". And that sounds suspiciously like a permission to
>>>>> both create new files but also to modify existing ones. If it is
>>>>> not, then which attribute would give the ability to modify existing
>>>>> files? It's really a shame that Microsoft didn't make each part of
>>>>> that a separate attribute.
>>>>>
>>>>
>>>> When you look in the advanced view the descriptions for the
>>>> individual ACEs have two parts separated by / char. On the
>>>> left is what the ACE means applied to a directory, on the right
>>>> what it means applied to a file. So, selection of that ACE and
>>>> in the dropbox set to This folder only allows only creating new
>>>> files in that directory (similarly applied to This folder and subs).
>>>
>>> Aha.... I think I just evolved. Thank you.
>>>
>>>
>>>> I think this could be seen as artifact of the era when designed
>>>> and all bits added up to significant cost, so something like a
>>>> double word is all that was allocated for all ACE flags, and
>>>> a couple of them for indication of applicability to objects and/or
>>>> container objects.
>>>
>>> Regardless of how badly they overloaded the implementation, the user
>>> interface of the Advanced Security Settings dialog for ACLs is fairly
>>> awful. It's way too compressed to easily pull out the explanation you
>>> gave just from usage. And in general the fact that the implementation
>>> is overloaded is not a great reason to overload the user interface in a
>>> parallel fashion.
>>>
>>> --
>>> Will
>
>