Stop pupils writing to root of C:\

[gerardsweeney]

Hello, all..

 

We have our systems formatted as NTFS (took us long enough!!).

 

One of the things I've noticed is that while pupils can't write to (say) C:\Program Files, or to existing folders in the root of C:\ they ARE able to create their own folder and then write to it.

 

This is allowing the little bugg - erm - darlings to install portable versions of apps/games to C:\

 

I'm assuming(!) that there's some easy way to fix this with NTFS and Subinacl, but for the life of me, I can't find it.

 

Any chance some kind soul can help me out here?

 

Regards,

Gerard

[srochford]

I *think* you want to add this to your startup script:

cacls c:\ /e /g users:r administrators:f system:f

but check it on one machine before you to do it to all of them!

This will change the existing permissions on this folder only (you need /t if you want to change the tree) but if there are folders lower down which are inheriting from this folder then you could break them.

[gerardsweeney]

I *think* you want to add this to your startup script:

cacls c:\ /e /g users:r administrators:f system:f

 

Hi..

 

Sorry - that didn't seem to work (bah!)..

 

I made the permissions change, but it doesn't seem to have worked.

 

Looking at the permissions for C:\

 

Under Advanced, Users and Everyone have "Create Folders/Append Data".

 

So far, it seems Subinacl and/or cacls don't overwrite this - unless I'm missing a particular switch, of course?!?!

 

Regards,

Gerard

[gjdb]

Mostlikely there are more directories they can use, some even needed like the \Windows\Temp dir.

 

Also check \Documents and Settings\All Users\Documents & \Documents and Settings\All Users\Application Data those maps also have user write permission on by default.

[gerardsweeney]

Hello, all..

 

In case anyone is ever faced with the same problem, I found the solution on SETACL's discussion forum.

 

https://sourceforge.net/projects/setacl/forums/forum/235314/topic/2190447

 

setacl -on "c:\\" -ot file -actn ace -ace "n:%COMPUTERNAME%\users; m:revoke; p:add_subdir; i:sc; w:dacl"

 

setacl -on "c:\\" -ot file -actn ace -ace "n:%COMPUTERNAME%\users; m:revoke; p:add_file; i:sc,io; w:dacl"

 

Regards,

Gerard

[JJonas]

Shouldnt the owner of the rogue folder be the user that made the folder. Stick them in detention make sure students are aware this is happening.

 

To find owner

 

right click rogue folder select properties

Click security tab

Click advanced

click owner

[storkyIV]

Don't you hide "my computer"???

[cookie_monster]

We use the File System GPO here to set this.

 

In a computer policy set the object name to %systemdrive%\ we then set the permissions below.

 

These two radio buttons are set: 'Configure this file or folder then' and 'Propogate inheritable permissions to all subfolders and files'.

 

SYSTEM: Full Control

Administrators: Full Control

Users: Read, List folder contents and Read and Execute (the basic read permissions)

 

 

http://windowsitpro.com/article/articleid/82361/jsi-tip-8724-how-can-i-use-group-policy-to-set-file-system-andor-registry-permissions.html

 

Read the Caution section in this link and remember to try on a test machine first.

 

http://technet.microsoft.com/en-us/library/cc739730(WS.10).aspx

Edited January 21, 2010 by cookie_monster

[Dos_Box]

Yup, group policies are your friend here. Does your school not use Active Directory?

[gerardsweeney]

JJonas - Yep, I'd been doing that before I found how to stop them.

 

The Librarians/teachers didn't seem that bothered, so there was no - shall we say - incentive for the kids to not do that.

 

storkyIV - Yes, My Computer has drives masked. However, installers of things like portable games will cheerfully let you install to C:\ by manually typing in the path, and then display a final dialog with "Launch gameyoujustinstalled" afterwards

 

cookie_monster/Dos_Box - Yep, we use AD but I was under the impression that doing this can have a knock-on effect of overwriting other NTFS permissions already in place... Say, for example, we need them to write to C:\Windows\IniFileForAProgram.ini (kind of idea)

 

Cheers,

Gerard

Edited January 21, 2010 by gerardsweeney
Reply to cookie_Monster/Dos_Box

[nicholab]

Software restriction policy will stop this.

[timzim]

In your pupil GPO:

User Config -> Administrative templates -> Windows Components -> Windows Explorer -> "Hide these specified drives in My Computer" & "Prevent access to these drives from My Computer"

 

Also MS KB231289 to see how to adapt the policy to suit your own requirements. Works nicely for us.

[gerardsweeney]

In your pupil GPO:

User Config -> Administrative templates -> Windows Components -> Windows Explorer -> "Hide these specified drives in My Computer" & "Prevent access to these drives from My Computer"

 

Yes, we use that...

 

However, the problem stems from our XP install method.. Or - at least it seems to

 

From what I can gather: if you install XP from CD, and allow ITS installer to do the partitioning and formatting, then C:\ is marked as read only.

 

The method we use to build a new PC is to deploy a blank NTFS partition, and then run the setup. This removes the stupidly long time it takes to format 300Gb

 

However, it appears(!) that if you use this method, that XP's installer adds a Special Permissions bit to the drive, which lets them create a new file/folder in C:\

 

They don't need to be able to SEE drive C: - the installer will quite happily let them type it in.

 

I suspect the problem lies with the original NTFS image - we basically chucked a drive into a USB caddy, formatted it as NTFS, shoved it back into a desktop and imaged it. I'm guessing Windows added the Creator_owner bit at that stage.

 

The write access doesn't carry down... For example, they can't write to C:\Windows or C:\Drivers, nor can Pupil1 write to a folder created by Pupil2 - but they can create C:\BLAHBLAH and install a non-registry-editing game to it.

 

Hope all of that makes sense

[cookie_monster]

JJonas - Yep, I'd been doing that before I found how to stop them.

 

The Librarians/teachers didn't seem that bothered, so there was no - shall we say - incentive for the kids to not do that.

 

storkyIV - Yes, My Computer has drives masked. However, installers of things like portable games will cheerfully let you install to C:\ by manually typing in the path, and then display a final dialog with "Launch gameyoujustinstalled" afterwards

 

cookie_monster/Dos_Box - Yep, we use AD but I was under the impression that doing this can have a knock-on effect of overwriting other NTFS permissions already in place... Say, for example, we need them to write to C:\Windows\IniFileForAProgram.ini (kind of idea)

 

Cheers,

Gerard

 

 

 

You can use the same GPO for setting permissions on other files and directories as well, we do this. Also the setting we use only sets those permissions on the root of C: as soon as you look in Program Files or Windows the permissions are default including Power Users and so on.

[gerardsweeney]

Also the setting we use only sets those permissions on the root of C:

 

Cool - I'll need to have a word with our AD bod (I am but a humble desktop tech).

 

Thanks for all of the replies, folks.

 

Gerard