I want to make sure that a group of users can't WRITE a set of filesthat they have to be able to READ. The files belonging to that setmight change over time, so I want to make it part of a logon script.

The problem is, I can use CACLS / XCACLS to DENY ALL access to thefile. or to GRANT read, write, etc privileges to the files.. But Ican't use them (or, probaby, I don't know how to do it) to just denywrite permissions for a given group.

Is there some util that I might use, or do I have to resort to VBS toaccomplish what I need to do? IF that's the case, HOW do I do it(sadly, whie I'm quite adept at batch scripting, VBS is not my forte).

However, a better solution might be reorganizing storageso that files in this category are within a subdirectory oftheir current location, rather than mixed into files of theother permissions category within a single directory.-- Roger AbellMicrosoft MVP (Windows Security)MCSE (W2k3,W2k,Nt4) MCDBA"Javier J" <no.mail@please.no> wrote in messagenews:cvc321lamb3mjim61lkfadd8f72kcdhc39@4ax.com...> Hi all!>> I want to make sure that a group of users can't WRITE a set of files> that they have to be able to READ. The files belonging to that set> might change over time, so I want to make it part of a logon script.>> The problem is, I can use CACLS / XCACLS to DENY ALL access to the> file. or to GRANT read, write, etc privileges to the files.. But I> can't use them (or, probaby, I don't know how to do it) to just deny> write permissions for a given group.>> Is there some util that I might use, or do I have to resort to VBS to> accomplish what I need to do? IF that's the case, HOW do I do it> (sadly, whie I'm quite adept at batch scripting, VBS is not my forte).>> Thanks a lot.>> Javier J

"Javier J" <no.mail@please.no> wrote in messagenews:cvc321lamb3mjim61lkfadd8f72kcdhc39@4ax.com...> Hi all!>> I want to make sure that a group of users can't WRITE a set of files> that they have to be able to READ. The files belonging to that set> might change over time, so I want to make it part of a logon script.>> The problem is, I can use CACLS / XCACLS to DENY ALL access to the> file. or to GRANT read, write, etc privileges to the files.. But I> can't use them (or, probaby, I don't know how to do it) to just deny> write permissions for a given group.

As a logon script, your code will run in the context of the user. If he hassufficient privileges to DENY himself write access, he has sufficientprivileges to REVOKE this denial.

Similarly, if he has ONLY READ/WRITE, but not FULL, then the script willfail to modify the permissions.

> Is there some util that I might use, or do I have to resort to VBS to> accomplish what I need to do? IF that's the case, HOW do I do it> (sadly, whie I'm quite adept at batch scripting, VBS is not my forte).

Doing permissions at the granular level from VBScript can be quite a chore.I would recommend that, using a privileged account, you permit the folders(and existing file) such that normal users can only read, and cannot write.New files created there will then inherit the same permissions/restrictionsautomatically.

"Roger Abell" <mvpNOSpam@asu.edu> wrote in messagenews:uIPY%23uNHFHA.2936@TK2MSFTNGP15.phx.gbl...> You are correct that xcacls.exe does not offer the granularity> for Deny settings that you are after.

In addition to that, also consider that it is often more appropriate tosimply not grant write access rather than actually denying it.

/Al

> You can download xcacls.vbs from the Microsoft site>http://www.microsoft.com/downloads/details.aspx?FamilyID=0ad33a24-0616-473c-b103-c35bc2820bda&DisplayLang=en> This does support the granularity you are after.>> However, a better solution might be reorganizing storage> so that files in this category are within a subdirectory of> their current location, rather than mixed into files of the> other permissions category within a single directory.> -- > Roger Abell> Microsoft MVP (Windows Security)> MCSE (W2k3,W2k,Nt4) MCDBA> "Javier J" <no.mail@please.no> wrote in message> news:cvc321lamb3mjim61lkfadd8f72kcdhc39@4ax.com...> > Hi all!> >> > I want to make sure that a group of users can't WRITE a set of files> > that they have to be able to READ. The files belonging to that set> > might change over time, so I want to make it part of a logon script.> >> > The problem is, I can use CACLS / XCACLS to DENY ALL access to the> > file. or to GRANT read, write, etc privileges to the files.. But I> > can't use them (or, probaby, I don't know how to do it) to just deny> > write permissions for a given group.> >> > Is there some util that I might use, or do I have to resort to VBS to> > accomplish what I need to do? IF that's the case, HOW do I do it> > (sadly, whie I'm quite adept at batch scripting, VBS is not my forte).> >> > Thanks a lot.> >> > Javier J>>

Al is quite right in picking up on your mention of use in alogin script - which skipped my attention.To do as you had planned you would need to do this ina startup/shutdown script, not login/logoff script.

However, you really, really would IMO be better off byrestructuring so that all files with this requirement are ina folder with appropriate grants, not mixed in with otherfiles in a folder where the default NTFS permissions willneed to be changed.

-- Roger AbellMicrosoft MVP (Windows Security)MCSE (W2k3,W2k,Nt4) MCDBA"Javier J" <no.mail@please.no> wrote in messagenews:cvc321lamb3mjim61lkfadd8f72kcdhc39@4ax.com...> Hi all!>> I want to make sure that a group of users can't WRITE a set of files> that they have to be able to READ. The files belonging to that set> might change over time, so I want to make it part of a logon script.>> The problem is, I can use CACLS / XCACLS to DENY ALL access to the> file. or to GRANT read, write, etc privileges to the files.. But I> can't use them (or, probaby, I don't know how to do it) to just deny> write permissions for a given group.>> Is there some util that I might use, or do I have to resort to VBS to> accomplish what I need to do? IF that's the case, HOW do I do it> (sadly, whie I'm quite adept at batch scripting, VBS is not my forte).>> Thanks a lot.>> Javier J

First of all, regarding LOGON SCRIPT, the mistake is mine: What I wastrying to talk about was a STARTUP script (if I'm not mistaken, thatscript runs as BUILTIN\SYSTEM).

I think I'd rather explain a bit more about the envirnoment so thatit's clear of why I'm asking for such strange things:

The situation is as follows: The PCs in question (Win 200 PRO, SP4+,W2000 Mixed Domain) "belong" to a group of users who, as part of theirnormal duties, have to handle sensitive information using an internalcompany app. To avoid undue information leakage, these users have*TWO* logon users for the domain, a highly restricted one that is usedto run the corporate app/access sensitve information, and a "Normal"user for the rest of everyday tasks.

The "normal" user can run all software EXCEPT the restricted app, andcan work normally.

The setup for the restricted user (using GPO, crypto software et al)is such that the restricted user only can run the "sensitive" app,they can't browse or "see" in Explorer the local folders, theirprofile is redirected to an encrypted network etc etc...

Also, using an STARTUP batch script, the members of the restrictedgroup have been DENIED access to different .exes that restricted usersshould not run (ftp.exe, telnet.exe and other) and folders they don'tneed access to. (Windows already protects system folders againstaccidental change). The problem is, there are a couple of folders onC:\ (such as c:\local_settings) that the user logon needs to be ableto read, because it sets machine-specific config. (such as thebuilding's mail server, the NT server, and suchlike)

The problem is that the folder is set to be writeable by "Everyone".I'd like to be able to "change" it so "no write" for the users of thisparticular group. I can DENY access, but these users are part of"Everyone", so even if "RestrictedG" has only READ acces, as they aremembers of "Everyone"; they get to write there...

Why am I exploring the "deny" route, instead of limiting the rights of"Everyone".. because there are some cases where the normal users hasto be able to write, so "Everyone:W" is a valid permission.... as longas I could do something like "RestrictedG":DENY WRITE....

I know that permission is "settable" (is that a word?) as it can beset usign (the "simple) NTFS Perms. tab... but to script it is what isdriving me crazy!!

>Al is quite right in picking up on your mention of use in a>login script - which skipped my attention.>To do as you had planned you would need to do this in>a startup/shutdown script, not login/logoff script.>>However, you really, really would IMO be better off by>restructuring so that all files with this requirement are in>a folder with appropriate grants, not mixed in with other>files in a folder where the default NTFS permissions will>need to be changed.

"Javier J" <no.mail@please.no> wrote in messagenews:vpf921h1j3tgiliegad4u4kj7e7urhl72l@4ax.com...> Hi!!>> Thanks a lot for the response.>> First of all, regarding LOGON SCRIPT, the mistake is mine: What I was> trying to talk about was a STARTUP script (if I'm not mistaken, that> script runs as BUILTIN\SYSTEM).>> I think I'd rather explain a bit more about the envirnoment so that> it's clear of why I'm asking for such strange things:>> The situation is as follows: The PCs in question (Win 200 PRO, SP4+,> W2000 Mixed Domain) "belong" to a group of users who, as part of their> normal duties, have to handle sensitive information using an internal> company app. To avoid undue information leakage, these users have> *TWO* logon users for the domain, a highly restricted one that is used> to run the corporate app/access sensitve information, and a "Normal"> user for the rest of everyday tasks.>> The "normal" user can run all software EXCEPT the restricted app, and> can work normally.>> The setup for the restricted user (using GPO, crypto software et al)> is such that the restricted user only can run the "sensitive" app,> they can't browse or "see" in Explorer the local folders, their> profile is redirected to an encrypted network etc etc...>> Also, using an STARTUP batch script, the members of the restricted> group have been DENIED access to different .exes that restricted users> should not run (ftp.exe, telnet.exe and other) and folders they don't> need access to. (Windows already protects system folders against> accidental change). The problem is, there are a couple of folders on> C:\ (such as c:\local_settings) that the user logon needs to be able> to read, because it sets machine-specific config. (such as the> building's mail server, the NT server, and suchlike)>> The problem is that the folder is set to be writeable by "Everyone".> I'd like to be able to "change" it so "no write" for the users of this> particular group. I can DENY access, but these users are part of> "Everyone", so even if "RestrictedG" has only READ acces, as they are> members of "Everyone"; they get to write there...>> Why am I exploring the "deny" route, instead of limiting the rights of> "Everyone".. because there are some cases where the normal users has> to be able to write, so "Everyone:W" is a valid permission.... as long> as I could do something like "RestrictedG":DENY WRITE....>> I know that permission is "settable" (is that a word?) as it can be> set usign (the "simple) NTFS Perms. tab... but to script it is what is> driving me crazy!!>> Thanks a lot. Any help _WILL_ Be more than welocome!!>> Javier J

The xcacls.vbs will do what you are after, and, it will provide youwith example of lines need to do it in your own script.

Deny overrides Grant - where you discuss need for Everyone, butnot the RestrictedG. The only thing is that you need to be very awareand careful about explicit vs inherited.Inherited or Explicit Deny overrides an Inherited GrantExplicit Deny overrides an Explicit Grant, but an Inherited Deny does not override an Explicit Grant.-- Roger

>> On Mon, 28 Feb 2005 22:12:30 -0700, "Roger Abell" <mvpNOSpam@asu.edu>> wrote:>> >Al is quite right in picking up on your mention of use in a> >login script - which skipped my attention.> >To do as you had planned you would need to do this in> >a startup/shutdown script, not login/logoff script.> >> >However, you really, really would IMO be better off by> >restructuring so that all files with this requirement are in> >a folder with appropriate grants, not mixed in with other> >files in a folder where the default NTFS permissions will> >need to be changed.>

"Javier J" <no.mail@please.no> wrote in messagenews:vpf921h1j3tgiliegad4u4kj7e7urhl72l@4ax.com...> Hi!!>> Thanks a lot for the response.

You are welcome...

> First of all, regarding LOGON SCRIPT, the mistake is mine: What I was> trying to talk about was a STARTUP script (if I'm not mistaken, that> script runs as BUILTIN\SYSTEM).>> I think I'd rather explain a bit more about the envirnoment so that> it's clear of why I'm asking for such strange things:>> The situation is as follows: The PCs in question (Win 200 PRO, SP4+,> W2000 Mixed Domain) "belong" to a group of users who, as part of their> normal duties, have to handle sensitive information using an internal> company app. To avoid undue information leakage, these users have> *TWO* logon users for the domain, a highly restricted one that is used> to run the corporate app/access sensitve information, and a "Normal"> user for the rest of everyday tasks.

Interesting. In our environment, any exceptionally privileged accounts arerestricted in what they can do only by policies written on paper rather thanbeing enforced by GPO. Admin accounts are not allowed to use the browser,but they are not actually prevented from doing so. We do not have anyapplications that need to be run in a context where the rest of theinfrastructure is made inaccessible, so access to such apps is granted tonormal user accounts.

> The "normal" user can run all software EXCEPT the restricted app, and> can work normally.>> The setup for the restricted user (using GPO, crypto software et al)> is such that the restricted user only can run the "sensitive" app,> they can't browse or "see" in Explorer the local folders, their> profile is redirected to an encrypted network etc etc...

.... still having some trouble envisioning how this type of operation can beconfigured without creating complications for adminstration. I mean, whohere can list all of the files on a Windows system to which ANY user MUSThave READ access? WRITE access?

> Also, using an STARTUP batch script,

Fine. But what if the system is not restarted between user sessions?

> the members of the restricted> group have been DENIED access to different .exes that restricted users> should not run (ftp.exe, telnet.exe and other) and folders they don't> need access to. (Windows already protects system folders against> accidental change). The problem is, there are a couple of folders on> C:\ (such as c:\local_settings) that the user logon needs to be able> to read, because it sets machine-specific config. (such as the> building's mail server, the NT server, and suchlike)>> The problem is that the folder is set to be writeable by "Everyone".> I'd like to be able to "change" it so "no write" for the users of this> particular group. I can DENY access, but these users are part of> "Everyone", so even if "RestrictedG" has only READ acces, as they are> members of "Everyone"; they get to write there...

The explicit DENY will generally override the ALLOW.

> Why am I exploring the "deny" route, instead of limiting the rights of> "Everyone".. because there are some cases where the normal users has> to be able to write, so "Everyone:W" is a valid permission.... as long> as I could do something like "RestrictedG":DENY WRITE....>> I know that permission is "settable" (is that a word?) as it can be> set usign (the "simple) NTFS Perms. tab... but to script it is what is> driving me crazy!!

I sympathize! But I fear that the approach may not be as bullet proof as youappear to need it to be.

Apparently members of the restricted group can logon and establish theirredirected session having only READ access to the "c:\local_settings\"folder. If it is possible to script a permissions change such that thefolder remains read/write for everyone except for the restricted group whohave read-only access, then surely it should be possible to apply thatpermission setting ONCE using the GUI, and just leave it at the setting youneed.

I tried this and it seemed to work, however, I had to put a checkmark besideWRITE in the DENY column. When I tried to DENY the MODIFY access, I found Icould not do so without also denying READ, READ&EXECUTE, and LIST FOLDERCONTENTS. That would appear to be a limitation or constraint applied by theGUI itself.

I would recommend that you try the following from the GUI: Everyone:W andRestrictedG:DENY WRITE, and then test the results to see if it achieves yourpurpose without causing problems for the restricated users.

If that fails in any way, then I would suggest drilling down to the advancedtab and denying everything associated with being able to modify or write.

If that fails in any way, then I would suggest playing with cacls orcacls.vbs to see if the extra granularity allows you to do what you want.

If THAT fails, then, IMHO, you will be unable to accomplish this in astartup script. If it succeeds, then you will not need to do it in a startupscript if you can configure the permissions of that folder as a default inyour image, or as part of the restricted application installation process.

/Al

> Thanks a lot. Any help _WILL_ Be more than welocome!!>> Javier J>> On Mon, 28 Feb 2005 22:12:30 -0700, "Roger Abell" <mvpNOSpam@asu.edu>> wrote:>> >Al is quite right in picking up on your mention of use in a> >login script - which skipped my attention.> >To do as you had planned you would need to do this in> >a startup/shutdown script, not login/logoff script.> >> >However, you really, really would IMO be better off by> >restructuring so that all files with this requirement are in> >a folder with appropriate grants, not mixed in with other> >files in a folder where the default NTFS permissions will> >need to be changed.>

>"Javier J" <no.mail@please.no> wrote in message>news:vpf921h1j3tgiliegad4u4kj7e7urhl72l@4ax.com...>> Hi!!>>>> Thanks a lot for the response.>>>> First of all, regarding LOGON SCRIPT, the mistake is mine: What I was>> trying to talk about was a STARTUP script (if I'm not mistaken, that>> script runs as BUILTIN\SYSTEM).>>

<...>

>> The problem is that the folder is set to be writeable by "Everyone".>> I'd like to be able to "change" it so "no write" for the users of this>> particular group. I can DENY access, but these users are part of>> "Everyone", so even if "RestrictedG" has only READ acces, as they are>> members of "Everyone"; they get to write there...>>>> Why am I exploring the "deny" route, instead of limiting the rights of>> "Everyone".. because there are some cases where the normal users has>> to be able to write, so "Everyone:W" is a valid permission.... as long>> as I could do something like "RestrictedG":DENY WRITE....>>>> I know that permission is "settable" (is that a word?) as it can be>> set usign (the "simple) NTFS Perms. tab... but to script it is what is>> driving me crazy!!>>>> Thanks a lot. Any help _WILL_ Be more than welocome!!>>>> Javier J>>The xcacls.vbs will do what you are after, and, it will provide you>with example of lines need to do it in your own script.>>Deny overrides Grant - where you discuss need for Everyone, but>not the RestrictedG. The only thing is that you need to be very aware>and careful about explicit vs inherited.>Inherited or Explicit Deny overrides an Inherited Grant>Explicit Deny overrides an Explicit Grant, but an Inherited> Deny does not override an Explicit Grant.

Thanks a lot. At the moment, I've managed to overcome the problem byisolating the folders where the needed .bat files are, and given"read" to Everyone, so the scripts are readable by all, and the "logto" folder .... well, I've used Deny for "RestrictedG", and I justlive w/o standard logging for that group (instead, I'm using eventlogto log events to the system event log), but I'd like to be able to dothinks in not such-a-radical approach.

>>"Javier J" <no.mail@please.no> wrote in message>news:vpf921h1j3tgiliegad4u4kj7e7urhl72l@4ax.com...>> Hi!!>>>> Thanks a lot for the response.>>You are welcome...>>> First of all, regarding LOGON SCRIPT, the mistake is mine: What I was>> trying to talk about was a STARTUP script (if I'm not mistaken, that>> script runs as BUILTIN\SYSTEM).>>>> I think I'd rather explain a bit more about the envirnoment so that>> it's clear of why I'm asking for such strange things:>>>> The situation is as follows: The PCs in question (Win 200 PRO, SP4+,>> W2000 Mixed Domain) "belong" to a group of users who, as part of their>> normal duties, have to handle sensitive information using an internal>> company app. To avoid undue information leakage, these users have>> *TWO* logon users for the domain, a highly restricted one that is used>> to run the corporate app/access sensitve information, and a "Normal">> user for the rest of everyday tasks.>>Interesting. In our environment, any exceptionally privileged accounts are>restricted in what they can do only by policies written on paper rather than>being enforced by GPO. Admin accounts are not allowed to use the browser,>but they are not actually prevented from doing so. We do not have any>applications that need to be run in a context where the rest of the>infrastructure is made inaccessible, so access to such apps is granted to>normal user accounts.>

Hi!

In the "normal" running of this org, that is the way things are. Butthis is a "small" group (around 50 users, max) that sometimes handleextremely sensitive (from the legal P.O.W.) info, so we have decidedto try to go the "extra mile" and "really" restrict the things.

Of course, the legal "threat" is still in place, but the consensus wasthat the user should also be "made aware" of the restricted naturea ofthe environment... If there is plenty of things that the user normallycan do that can't be done, the user can't (honestly, justifibly) say"I was not aware of that"...

>> The "normal" user can run all software EXCEPT the restricted app, and>> can work normally.>>>> The setup for the restricted user (using GPO, crypto software et al)>> is such that the restricted user only can run the "sensitive" app,>> they can't browse or "see" in Explorer the local folders, their>> profile is redirected to an encrypted network etc etc...>>... still having some trouble envisioning how this type of operation can be>configured without creating complications for adminstration. I mean, who>here can list all of the files on a Windows system to which ANY user MUST>have READ access? WRITE access?

Well, basically it's not that difficult.Normal users only need read access to %windir% and to %programfiles%(ant that's the defaul windows user perms), and write access to theirown user profile.

So any other folder (for example, those hanging from C: that are _not_c:\winnt or c:\Program Files or c:\Documents and Settings) are thefolders I worry about.

As for the temporary folders, and swap file, and such, the system isset to clear them on shutdown, and the user profile can't "closesession", only "restart".

>> Also, using an STARTUP batch script,>>Fine. But what if the system is not restarted between user sessions?>

Well, those policies are applied _each_ time the system boots, but anormal user shouldn't be able to change them (as they're not membersof the admin group), so it's probably a bit of overkill to have thepolicies re-set on each machine boot...

On user logon and logoff there is a more limited script that performstemporary file deletion and such niceties as we could think of...

Also, we are exploring the possibility of forcing the user to rebootthe computer when they logoff the "restricted user", but thats only onthe drawing board at the moment.

>> the members of the restricted>> group have been DENIED access to different .exes that restricted users>> should not run (ftp.exe, telnet.exe and other) and folders they don't>> need access to. (Windows already protects system folders against>> accidental change). The problem is, there are a couple of folders on>> C:\ (such as c:\local_settings) that the user logon needs to be able>> to read, because it sets machine-specific config. (such as the>> building's mail server, the NT server, and suchlike)>>>> The problem is that the folder is set to be writeable by "Everyone".>> I'd like to be able to "change" it so "no write" for the users of this>> particular group. I can DENY access, but these users are part of>> "Everyone", so even if "RestrictedG" has only READ acces, as they are>> members of "Everyone"; they get to write there...>>The explicit DENY will generally override the ALLOW.

That's why I'm trying to "get" how to be able to selectively DENY somethings, as I'd rather not deny everything

>>> Why am I exploring the "deny" route, instead of limiting the rights of>> "Everyone".. because there are some cases where the normal users has>> to be able to write, so "Everyone:W" is a valid permission.... as long>> as I could do something like "RestrictedG":DENY WRITE....>>>> I know that permission is "settable" (is that a word?) as it can be>> set usign (the "simple) NTFS Perms. tab... but to script it is what is>> driving me crazy!!>>I sympathize! But I fear that the approach may not be as bullet proof as you>appear to need it to be.

Well.... I am aware that there is no perfect solution to the problem.What I'm trying to do is to configuire the system so it's *notably*(at least, from my POV) more secure than it was, and to do so in sucha way that the user's productivity does not suffer too much...

>>Apparently members of the restricted group can logon and establish their>redirected session having only READ access to the "c:\local_settings\">folder. If it is possible to script a permissions change such that the>folder remains read/write for everyone except for the restricted group who>have read-only access, then surely it should be possible to apply that>permission setting ONCE using the GUI, and just leave it at the setting you>need.>>I tried this and it seemed to work, however, I had to put a checkmark beside>WRITE in the DENY column. When I tried to DENY the MODIFY access, I found I>could not do so without also denying READ, READ&EXECUTE, and LIST FOLDER>CONTENTS. That would appear to be a limitation or constraint applied by the>GUI itself.>>I would recommend that you try the following from the GUI: Everyone:W and>RestrictedG:DENY WRITE, and then test the results to see if it achieves your>purpose without causing problems for the restricated users.

YES! That's the final result I want to achieve, but using a script. Ialready have tested those changes on the GUI, the "problem" is gettingthe computers to that state w/o having to log-on to them.

>If that fails in any way, then I would suggest drilling down to the advanced>tab and denying everything associated with being able to modify or write.>>If that fails in any way, then I would suggest playing with cacls or>cacls.vbs to see if the extra granularity allows you to do what you want.

No, I only need to be able to do the same than in the "standard" filepermission tab, BUT w/o doing it manually.

>If THAT fails, then, IMHO, you will be unable to accomplish this in a>startup script. If it succeeds, then you will not need to do it in a startup>script if you can configure the permissions of that folder as a default in>your image, or as part of the restricted application installation process.>

The issue here is that the install image is already "closed", and itdepends on another dept. that I don't have "leverage" with. And thatinstallation image could change with time (for instance, when newhardware is bought). What I am trying to do is to find a way to"transform" the image from the permssions-state that it has, to theone I want it to have, so that I can be confident that "accidents"don't happen (say, one of the Domain Admins logs on the computer, andmakes some changes, or whatever). That's why I'm investigatingsoftware installation policies, permission change scripts and thelike..

The idea is to develop a "method" to be able to securize a givencomputer, not only a "lock this specific workstation" approach. And tominimize the manual intervention required. (as it is, it's stillnecessary to log on to the computer as local admin at least once, sothat MS OUTLOOK is completely installed.... And I don't know whyshould it behave like that, it's.. odd and uncomfortable, to say theleast)... BTW, if you know of any way of avoiding that, I'd be morethan happy to hear it!!

>/Al>>> Thanks a lot. Any help _WILL_ Be more than welocome!!>>>> Javier J>>>> On Mon, 28 Feb 2005 22:12:30 -0700, "Roger Abell" <mvpNOSpam@asu.edu>>> wrote:>>>> >Al is quite right in picking up on your mention of use in a>> >login script - which skipped my attention.>> >To do as you had planned you would need to do this in>> >a startup/shutdown script, not login/logoff script.>> >>> >However, you really, really would IMO be better off by>> >restructuring so that all files with this requirement are in>> >a folder with appropriate grants, not mixed in with other>> >files in a folder where the default NTFS permissions will>> >need to be changed.>>>