Re: File/directory permissions

From: Roger Abell (mvpNOSpam_at_asu.edu)
Date: 06/14/05 

Date: Mon, 13 Jun 2005 23:43:31 -0700

"Grace" <yyy@yyy.com> wrote in message
news:edQ0xoFcFHA.720@TK2MSFTNGP15.phx.gbl...
>
> "Oli Restorick [MVP]" <oli@mvps.org> wrote in message
> news:u%23yhrZFcFHA.1568@TK2MSFTNGP10.phx.gbl...
> > Unless I'm missing something, I don't see that this scenario as being
> > complex at all.
> >
> > When you create the root directory, I'd set the ACL to
> > builtin\administrators:F. Don't give any users access (you'll be used
to
> > this, coming from a Netware background). That way, any newly-created
> > projects will have the right permissions by default.
> >
> > Then, create a group corresponding to each project, and set the ACL to
> allow
> > members of the group change permissions (C).
> >
> > If you prefer to do this from the command prompt, the following command
> > would do the trick.
> >
> > cacls g:\projects\client1\94m43 /t /e /g proj94m43:C
> >
> > From what you've said, the ACL I'd use on the share would be
> > builtin\administrators:F, builtin\users:C
> >
> > Where this scenario would get complex is if you wanted certain groups of
> > users to be able to access only, for example, the calculations folders
for
> > each project they're working on. I haven't yet seen a convincing
solution
> > to that problem.
> >
> > Regards
> >
> > Oli
> >
> >
> >
> > "Grace" <yyy@yyy.com> wrote in message
> > news:ekglsXEcFHA.3932@TK2MSFTNGP12.phx.gbl...
> > > Scenario - Windows 2000 Server SP4, name server1:
> > >
> > > Created a share on the server called shared$
> > >
> > > On users' PCs g: is mapped to \\server1\shared$
> > >
> > > directories on g:
> > >
> > > projects
> > >
> > > client1
> > > - 94m43
> > > admin
> > > estimate
> > > calculations
> > > - 94m44
> > > admin
> > > estimate
> > > calculations
> > >
> > > client2
> > > - 99r33
> > > admin
> > > junk
> > > letters
> > >
> > > I know that I cannot limit what users will see at the root of g:, like
> in
> > > Netware environment
> > >
> > > I need the following file permissions:
> > >
> > > users need to have g: mapped to the "shared$"
> > >
> > > Then for example, a global group "Proj94m43" needs to be able to do
> > > anything
> > > in admin, estimate, calculation directories but it cannot create
> > > directories
> > > or files directly under 94m43. Also, I don't want this group to be
able
> > > to
> > > open files in other projects, for example 94m44 or client2\99r33, even
> for
> > > read only. Admins should have access everywhere, of course.
> > >
> > > Another group, "Proj99r33" will need to work client2\99r33
> subdirectories,
> > > same way as above. There will be new groups, new project
subdirectories
> > > established when we get more work.
> > >
> > > I thought about leaving the share permissions alone (at default) and
> > > control
> > > everything thru NTFS but how exactly do I need to set it?
> > >
> > > I understand how they work together (share, ntfs), how they add up
under
> > > ntfs, but I need real world examples for complicated setups like mine.
> I
> > > am
> > > moving from Netware and permissions are turning into a nightmare.
> > >
> > > I appreciate help with the above and pointers to sites
> > > w/explanations/examples more involved than basic.
> > >
>
>
> Thanks, Oli, for your response. Let me see if I understand it correctly:
>
> share permissions: builtin\administrators:F, builtin\users:C (remove
> Everyone)
>
> then, ntfs permissions:
> root of g: (let's say directory name is data)
> builtin\administrators:F
>
> and for the project:
> cacls g:\projects\client1\94m43 /t /e /g proj94m43:C
>
> But won't they (Proj94m43 group) be able to create subdirectories under
> 94m43 this way?
>
> Sorry if I sound dumb, I'm trying to learn... Thanks,
>
>

You have restated it well, and also noticed that Oli apparently overlooked
the requirement that the users not be able to create new subfolders or files
directly under a project's folder.

If you were to set the permissions manually in the NTFS Security dialog,
assuming each project of say Client1 is to be totally separate from the
other projects of Client1, then at the folder for the project you would
grant List folder contents, and Read to the group of the project.
The Read is not needed if there will be no files directly under the
project's directory but instead only the subfolders, and it would need
to be Read/Execute if there are to be executables directly under the
project's directory.
This grant could be done, using the prior example with
cacls g:\projects\client1\94m43 /t /e /g proj94m43:R

Then, and this part is not easily done with Cacls (but is with xcacls)
on each subfolder within the project's directoy one would grant Modify
to the project group. Now, in order to prevent them from modifying
(as in deleting) the sobfolder itself you would click on Advanced to leave
the generic grants view of the ACL and select the newly added grant to
proj98m43 and use the edit button to access the bits of the ACE where
you would use the Applies to dropbox to change the setting from
This folder, subfolders, and file to instead say Subfolders and files.

So, you end up with something like

projects < Admins full from here on down

   client1 < This would be a good place to set Read for Client1
owner/auditor etc.
      - 94m43 < group proj94m43 gets read (execute) from here on down
               admin < group proj94m43 gets change within this (not of
this)
               estimate < group proj94m43 gets change within this (not of
this)
               calculations < group proj94m43 gets change within this (not
of this)
      - 94m44 < group proj94m44 gets read (execute) from here on down
               admin < group proj94m44 gets change within this (not of
this)
               estimate < group proj94m44 gets change within this (not of
this)
               calculations < group proj94m44 gets change within this (not
of this)

Finally, it actually is possible to set the three identical subfolder grants
on
their parent so that the permission does not apply to the parent but is only
inherited from it, but that is a little tricky without direct setting of the
ACE bits.

xcacls is more flexible that is cacls and the script version xcacls.vbs
(available at microsoft.com/downloads) is even more flexible when
it comes to setting grants/denies that are not "generic" (applying set
combinations to This folder, subfolders and files). 

-- 
Roger