dslreports logo
site
 
    All Forums Hot Topics Gallery
spc

spacer




how-to block ads


Search Topic:
uniqs
1367
share rss forum feed


yahtzee
Premium
join:2000-12-03
Richmond, VA

[WIN7] How to block access to Windows Explorer?

I have my pc set up with two different accounts...my account is the admin user and I have my daughter's set up as a standard user.....I want to block access to specific drives/folders under windows explorer when they are logged in. How do I do that?
--
If ever offered a breath mint - take it.

s_becker

join:2013-04-05
You could either use third party software to do so (I have nothing to recommend there) or using the group policies.

But I'm sorry. I can't point you to the group policy to do what you want.


norwegian
Premium
join:2005-02-15
Outback

1 edit
reply to yahtzee
You can delete the user off the security tab for the user in question.
However this really is better for just data files etc, as you start messing with program files and/or %ProgramData%, or %Windows% you might make things you want to run for her to stop working.

The other option short term is just use the Hidden attribute and hide the files and or directories from the users you choose.
--
The only thing necessary for the triumph of evil is for good men to do nothing - Edmund Burke


dave
Premium,MVM
join:2000-05-04
not in ohio
kudos:8
Reviews:
·Verizon FiOS

1 recommendation

reply to yahtzee
Blocking use of "Explorer" is insufficient, since practically any file-open dialog in any application can do much of what Explorer can do.

Blocking Explorer as per literal interpretation of your title (rather than blocking what Explorer can do) is problematic too, in that the desktop display is Explorer.

File protection and group policies are the appropriate approach, IMO.


yahtzee
Premium
join:2000-12-03
Richmond, VA
Honestly, blocking access to an entire drive would be ideal (if that's easy). How would I do that?
--
If ever offered a breath mint - take it.


norwegian
Premium
join:2005-02-15
Outback

What O/S? Windows 7, XP, or 8 and what flavor, home, home premium, professional etc.

That way more can be explained as each has a differing rule to work with in setting the permissions.
--
The only thing necessary for the triumph of evil is for good men to do nothing - Edmund Burke



yahtzee
Premium
join:2000-12-03
Richmond, VA
Windows 7 Professional. Thanks!


Kilroy
Premium,MVM
join:2002-11-21
Saint Paul, MN

1 edit
reply to yahtzee
Right click the drive and select properties. Change to the Security tab. Remove Authenticated Users and User\Machine Name\Users. I'd recommend that you add your admin account and give it Full control.
--
corrected spelling error

dave
Premium,MVM
join:2000-05-04
not in ohio
kudos:8
AFAIK, that is not removing access to "the drive" - that is removing access to the root directory on the drive. You can still open C:\foobar even if you can't list the contents of C:\


workablob

join:2004-06-09
Houston, TX
kudos:4
Reviews:
·Comcast
reply to yahtzee
Click for full size
This would be where I would start.

Note that it does not prevent access to the drives but merely hides them.

Anyone could open explorer and explicitly enter C:\ or D:\ and gain access.

But, this will stop most ordinary users and it is safer than messing with NTFS permissions.

Blob

EDIT. START/RUN gpedit.msc
--
I may have been born yesterday. But it wasn't at night.


Cartel
Premium
join:2006-09-13
Chilliwack, BC
kudos:2
Reviews:
·TekSavvy DSL
·Shaw
·TELUS
reply to yahtzee
Click for full size
Try this

»www.howtogeek.com/howto/windows-···s-vista/

Editor’s note: The files and folders within your user directory should already be off-limits to other regular users on your computer. Of course, if the other users are administrators, they can always reset any of these permissions, including deny. The main reason to use this technique would be if you are trying to remove access to folders on another drive, for instance hiding sensitive documents from children, etc. Just make sure those user accounts don’t have administrator access.


norwegian
Premium
join:2005-02-15
Outback
reply to dave
said by dave:

AFAIK, that is not removing access to "the drive" - that is removing access to the root directory on the drive. You can still open C:\foobar even if you can't list the contents of C:\

I would have thought this would have helped.

I wouldn't think a limited user could still access this sort of information without an admin password if the security policy doesn't allow access, as an admin would need to allow elevation of the permission.
--
The only thing necessary for the triumph of evil is for good men to do nothing - Edmund Burke


dave
Premium,MVM
join:2000-05-04
not in ohio
kudos:8
Reviews:
·Verizon FiOS
I'm not sure I understand your objection, so I can only repeat: you don't need access to C:\ to get access to C:\foo or to C:\foo\bar.

Of course, if you naively attempt to view C:\ as a precursor to opening C:\foo, then you'll get an access-denied error, but if you start in C:\foo -- for example, by typing C:\foo in the address bar -- you're good.

Sure, you have to *know* C:\foo exists.


norwegian
Premium
join:2005-02-15
Outback

I'm not objecting at all, I just thought it would work and certainly didn't think just typing into the address bar you would have access, if you knew a file directory location.
I've learnt something.
I would have thought as cmd line at the root was not available either you would be good to go.

So does that leave icalcs or something similar at all that would stop it's access, but from what you are saying it would be useless too if the user had some idea of the directory listing for the hidden drive?

You do mention group policy, would what workablob See Profile suggested be of value?

Interesting topic.
--
The only thing necessary for the triumph of evil is for good men to do nothing - Edmund Burke


dave
Premium,MVM
join:2000-05-04
not in ohio
kudos:8
Reviews:
·Verizon FiOS
The full story is: if access were checked at every level in C:\foo\bar\wibble\wibble\wibble\some\where\over\the\rainbow for every file access, then the OS would be significantly slower (so they say).

Thus, non-checking of intermediate directories that are 'traversed' on the way to opening something.

However:

Non-checking is controlled by a user privilege that is (unusually for privileges) granted to all users by default: Bypass Traverse Checking.

You can in principle remove this privilege from a user account and then the system will behave the way you're expecting.

However, I wouldn't recommend it: it's unusual to do that (and I have never tried it) and who knows what weird breakage will result?

»blogs.technet.com/b/markrussinov···ege.aspx


Dude111
An Awesome Dude
Premium
join:2003-08-04
USA
kudos:12
reply to dave

 

said by dave :
AFAIK, that is not removing access to "the drive" - that is removing access to the root directory on the drive. You can still open C:\foobar even if you can't list the contents of C:\
Even if you have C:\* blocked?? (* = ANYTHING)

s_becker

join:2013-04-05
reply to dave

Re: [WIN7] How to block access to Windows Explorer?

said by dave:

AFAIK, that is not removing access to "the drive" - that is removing access to the root directory on the drive. You can still open C:\foobar even if you can't list the contents of C:\

This is not wrong but not completely right either.
Most of the time, many object permissions are inherited from the parent object.
For system folders like 'program files' or 'windows' or 'users' this isn't true since windows defines special permissions to this folders. But for the underlying folders this is true or for a non-system drive like a data partition. The folders created there becomm their permissions inherited from the parent object.
To change the permissions of the child objects, there is the option to inherit the permissions to them in the 'Advanced Security Settings' of an object.

But the OP should be careful. If he changed the permissions to the system directories, directly or indirectly by changing the driver permissions and inheriting the permissions through, it can cause a lot of problems.

He should'nt change permissions on the system drive at all. Non-system drives are a different story.

dave
Premium,MVM
join:2000-05-04
not in ohio
kudos:8
Reviews:
·Verizon FiOS
reply to Dude111

Re:  

said by Dude111:

Even if you have C:\* blocked?? (* = ANYTHING)

The only security descriptor that actually prevents local access to a particular file is the security descriptor on that file itself.

Therefore, you'd have to remove access to everything.

(Network share access is a different story: the share-level access control list in effect says the maximum access you can have to anything underneath it).

dave
Premium,MVM
join:2000-05-04
not in ohio
kudos:8
Reviews:
·Verizon FiOS

1 edit
reply to s_becker

Re: [WIN7] How to block access to Windows Explorer?

said by s_becker:

Most of the time, many object permissions are inherited from the parent object.

Sure, but that's not a file-open-time phenomenon: the inheritable changes are 'flowed down' when made. So if you change the security on C:\ and invoke the 'propagate downwards' option, at that time the changes are copied everywhere (until you bump into objects that are configured to block such propagation).

Thus, in terms of what is on the disk, if you add an entry 'deny=dave:full control' to C:\ and flow it down to C:\foo, then it's the (copy of that) entry on C:\foo that blocks my access, not the one on C:\

I suppose I tend to describe things from the low-level programmer point of view rather than the end-user. Thus, to me, "the security on C:\foo" is talking about what you end up with, regardless of whether you actually typed it in to a UI when you were operating on C:\.

ACE inheritability is, IMO, best seen as a system management aid; it's not involved when opening a file.

I agree with the sentiment that "you don't want to do this". A lot of damage can result.

Perhaps if the OP gave some concrete examples of what he was worried about, we could be more explicit about what to do.

bbear2
Premium
join:2003-10-06
94045
kudos:5
reply to yahtzee
said by yahtzee:

Honestly, blocking access to an entire drive would be ideal (if that's easy). How would I do that?

There is a program called TrueCrypt, it's a free download. You can encrypt all that you do not want others to get access to. Although, when you want access, you will have to enter a password that will decrypt the drive; once per session.

s_becker

join:2013-04-05
reply to dave
said by dave:

Sure, but that's not a file-open-time phenomenon: the inheritable changes are 'flowed down' when made. So if you change the security on C:\ and invoke the 'propagate downwards' option, at that time the changes are copied everywhere (until you bump into objects that are configured to block such propagation).

Thus, in terms of what is on the disk, if you add an entry 'deny=dave:full control' to C:\ and flow it down to C:\foo, then it's the (copy of that) entry on C:\foo that blocks my access, not the one on C:\

I completely agree with you. When setting the permissions and inheriting them down, the settings get basically copied to the underlying objects.

BUT...

It's not directly copied, I think. The objects are set to inherit. You can test this by opening the Advanced Security Settings of a folder you created on drive D for example and remove the check box of "Included inheritable permissions from this object's parent". You will immediately get asked if you want to copy (it's called 'Add' in the dialog) the permissions from the parent object to his object or if you want to remove the permissions.
I thought the reason for this might be that newly created objects now if they should inherit the permissions from the parent object (when the parent is already set to inherit) or not. But when thinking about it... it doesn't make much sense.

But don't get me wrong. You are completely right and I think you for the clarification.

dave
Premium,MVM
join:2000-05-04
not in ohio
kudos:8
Reviews:
·Verizon FiOS

1 recommendation

said by s_becker:

It's not directly copied, I think.

Yeah, it is. It so happens I have to deal with this nonsense at a relatively low level - and if you fetch the security descriptor from a file, there are a bunch of ACEs marked 'inherited' (one bit, doesn't say where inherited from). And if you add a security descriptor built "from scratch" and use a low enough API, the file system does not insert the inheritable ACEs from the parent. Both of these issues show up when you are writing code to copy a file with its permissions (and not just using the CopyFile API). I'm also pretty sure I could add ACEs that claimed to be inherited but are not present anywhere in the ancestor directory chain.

None of that's conclusive proof, of course: fetching the SD from a file could dynamically collect all inherited ACEs. And so on. Though the 'marked as inherited but not present in the ancestor chain' experiment would seem to clinch the matter. I've never intentionally done that; never felt the need. The system acts completely as if every file system object had a complete copy of its entire ACL rather than any merging being needed (the physical residence of the ACL in a separate metadata file is not contrary to this statement).

If this were not all true, then checking file access at 'open' time would require reading the security descriptor of every ancestor directory before the effective ACL was available to check. We know from elsewhere (the existence of 'bypass traverse checking') that the system designers found that to be excessive overhead.

You will immediately get asked if you want to copy (it's called 'Add' in the dialog) the permissions from the parent object to his object or if you want to remove the permissions.

That's UI fiction. The operations could be labelled "keep the inherited ACEs but remove the inheritance indication" or "remove the inhertied ACEs".

--
Sorry, this post turned out longer than intended. I get carried away sometimes.