«

I have this senario:

Create a folder on Windows 2003 Ent. Ed. server, share it as Everyone: Full
Access.

Security permissions on folder:
Administrators: Full Control
CREATOR OWNER: Full Control
SYSTEM: Full Control
Test Group: Read, Create, Write, Append

So when a user of Test Group creates a file or folder on the share they
become Creator Owner and have full access to that file or folder. But they
cannot delete files or folders created by other users.

Test
1. Create a file in the folder as domain admin.
2. Map to the share as a user in Test Group and try delete the file. You get
permission denied which is expected.
3. As the mapped user, create a folder in the share.
4. Now create a file in that created folder as domain admin.
5. Check permissions on the newly created file. Test Group or user has no
delete permissions. Running Effective Permissions against the user also shows
no delete permissions.
6. Try delete the file as the user, file is deleted!

I assume the file can be deleted because the user is the Creator Owner of
the parent folder which propegated Full Access down to the file. But this
does not show up on the file's security settings. Why is that?

In article <FB75FBCF-DD69-43A4-A2D3->,
says...
> I have this senario:
>
> Create a folder on Windows 2003 Ent. Ed. server, share it as Everyone: Full
> Access.
>
> Security permissions on folder:
> Administrators: Full Control
> CREATOR OWNER: Full Control
> SYSTEM: Full Control
> Test Group: Read, Create, Write, Append
>
> So when a user of Test Group creates a file or folder on the share they
> become Creator Owner and have full access to that file or folder. But they
> cannot delete files or folders created by other users.
>
> Test
> 1. Create a file in the folder as domain admin.
> 2. Map to the share as a user in Test Group and try delete the file. You get
> permission denied which is expected.
> 3. As the mapped user, create a folder in the share.
> 4. Now create a file in that created folder as domain admin.
> 5. Check permissions on the newly created file. Test Group or user has no
> delete permissions. Running Effective Permissions against the user also shows
> no delete permissions.
> 6. Try delete the file as the user, file is deleted!

Right, this is the expected behavior.

> I assume the file can be deleted because the user is the Creator Owner of
> the parent folder which propegated Full Access down to the file. But this
> does not show up on the file's security settings. Why is that?
>

Because the permission the user is exercising is not on the file - it is
on an object in the folder he has full control over. I will admit, it is
a bit confusing.

Ok, I understand that part. I'm still not rock solid about why it isn't
visible through Secuity or Effective Permissions of that file object.

I guess my question would be, how would you know that a user of Test Group
could delete any files and folders under that directory just by looking at
the security of one of those files or folders? What if you have a scenario
where a file is buried under 100's of directories, the top one being owned by
some specific user, how hard would it be to determine that that file could be
deleted by the user owning the top dir? How do you see that this user has any
control over this file without winding your way up all the directories and
looking for permissions. There must be an easier way? Effective Permissions
tab does not help, as this reports no delete permission but it is in fact
allowed.

"Ben Smith" wrote:

> In article <FB75FBCF-DD69-43A4-A2D3->,
> says...
> > I have this senario:
> >
> > Create a folder on Windows 2003 Ent. Ed. server, share it as Everyone: Full
> > Access.
> >
> > Security permissions on folder:
> > Administrators: Full Control
> > CREATOR OWNER: Full Control
> > SYSTEM: Full Control
> > Test Group: Read, Create, Write, Append
> >
> > So when a user of Test Group creates a file or folder on the share they
> > become Creator Owner and have full access to that file or folder. But they
> > cannot delete files or folders created by other users.
> >
> > Test
> > 1. Create a file in the folder as domain admin.
> > 2. Map to the share as a user in Test Group and try delete the file. You get
> > permission denied which is expected.
> > 3. As the mapped user, create a folder in the share.
> > 4. Now create a file in that created folder as domain admin.
> > 5. Check permissions on the newly created file. Test Group or user has no
> > delete permissions. Running Effective Permissions against the user also shows
> > no delete permissions.
> > 6. Try delete the file as the user, file is deleted!
>
> Right, this is the expected behavior.
>
> > I assume the file can be deleted because the user is the Creator Owner of
> > the parent folder which propegated Full Access down to the file. But this
> > does not show up on the file's security settings. Why is that?
> >
>
> Because the permission the user is exercising is not on the file - it is
> on an object in the folder he has full control over. I will admit, it is
> a bit confusing.
>

In article <8B57EEC6-BDE3-4A7C-94AD->,
says...
> Ok, I understand that part. I'm still not rock solid about why it isn't
> visible through Secuity or Effective Permissions of that file object.

I am not sure how the UI calculates the effective permissions. Take a
look at the Test group's permission on the folder. You should see that
the permission is to the Folder and all objects in the folder, but the
explicit permission are only on folder objects, not file objects (which
would explain the results of the effective permissions tab.)

> I guess my question would be, how would you know that a user of Test Group
> could delete any files and folders under that directory just by looking at
> the security of one of those files or folders? What if you have a scenario
> where a file is buried under 100's of directories, the top one being owned by
> some specific user, how hard would it be to determine that that file could be
> deleted by the user owning the top dir? How do you see that this user has any
> control over this file without winding your way up all the directories and
> looking for permissions. There must be an easier way? Effective Permissions
> tab does not help, as this reports no delete permission but it is in fact
> allowed.

You point is well-taken. I will run some tests next week and file a bug
on it.

> "Ben Smith" wrote:
>
> > In article <FB75FBCF-DD69-43A4-A2D3->,
> > says...
> > > I have this senario:
> > >
> > > Create a folder on Windows 2003 Ent. Ed. server, share it as Everyone: Full
> > > Access.
> > >
> > > Security permissions on folder:
> > > Administrators: Full Control
> > > CREATOR OWNER: Full Control
> > > SYSTEM: Full Control
> > > Test Group: Read, Create, Write, Append
> > >
> > > So when a user of Test Group creates a file or folder on the share they
> > > become Creator Owner and have full access to that file or folder. But they
> > > cannot delete files or folders created by other users.
> > >
> > > Test
> > > 1. Create a file in the folder as domain admin.
> > > 2. Map to the share as a user in Test Group and try delete the file. You get
> > > permission denied which is expected.
> > > 3. As the mapped user, create a folder in the share.
> > > 4. Now create a file in that created folder as domain admin.
> > > 5. Check permissions on the newly created file. Test Group or user has no
> > > delete permissions. Running Effective Permissions against the user also shows
> > > no delete permissions.
> > > 6. Try delete the file as the user, file is deleted!
> >
> > Right, this is the expected behavior.
> >
> > > I assume the file can be deleted because the user is the Creator Owner of
> > > the parent folder which propegated Full Access down to the file. But this
> > > does not show up on the file's security settings. Why is that?
> > >
> >
> > Because the permission the user is exercising is not on the file - it is
> > on an object in the folder he has full control over. I will admit, it is
> > a bit confusing.
> >
>

Security Effective Permissions doesn't take into account any SHARE
permissions only the NTFS permissions. And if you are looking for creator
owner permissions then you would need to use CREATOR OWNER in the effective
permissions user dialog box.

--
..rev.mct.mcngp.44

It is the mark of an educated man to be able to entertain a thought without
accepting it.
~Aristotle
..
"Colin" <> wrote in message
news:FB75FBCF-DD69-43A4-A2D3-...
>I have this senario:
>
> Create a folder on Windows 2003 Ent. Ed. server, share it as Everyone:
> Full
> Access.
>
> Security permissions on folder:
> Administrators: Full Control
> CREATOR OWNER: Full Control
> SYSTEM: Full Control
> Test Group: Read, Create, Write, Append
>
> So when a user of Test Group creates a file or folder on the share they
> become Creator Owner and have full access to that file or folder. But they
> cannot delete files or folders created by other users.
>
> Test
> 1. Create a file in the folder as domain admin.
> 2. Map to the share as a user in Test Group and try delete the file. You
> get
> permission denied which is expected.
> 3. As the mapped user, create a folder in the share.
> 4. Now create a file in that created folder as domain admin.
> 5. Check permissions on the newly created file. Test Group or user has no
> delete permissions. Running Effective Permissions against the user also
> shows
> no delete permissions.
> 6. Try delete the file as the user, file is deleted!
>
> I assume the file can be deleted because the user is the Creator Owner of
> the parent folder which propegated Full Access down to the file. But this
> does not show up on the file's security settings. Why is that?

In article <8B57EEC6-BDE3-4A7C-94AD->,
says...
> Subject: Re: Permissions question
> From: =?Utf-8?B?Q29saW4=?= <>
> Newsgroups: microsoft.public.cert.exam.mcse
>
> Ok, I understand that part. I'm still not rock solid about why it isn't
> visible through Secuity or Effective Permissions of that file object.
>
> I guess my question would be, how would you know that a user of Test Group
> could delete any files and folders under that directory just by looking at
> the security of one of those files or folders? What if you have a scenario
> where a file is buried under 100's of directories, the top one being owned by
> some specific user, how hard would it be to determine that that file could be
> deleted by the user owning the top dir? How do you see that this user has any
> control over this file without winding your way up all the directories and
> looking for permissions. There must be an easier way? Effective Permissions
> tab does not help, as this reports no delete permission but it is in fact
> allowed.
>

I ran this test on XPSP2. The test user did not show up in the file ACL,
as expected, but the effective permissions tab did show that the test
user had modify permissions on the file.

Steps:

1) Create share on HOST (HOST\Share) for c:\test1 as Ben, an
administrator
2) Change Share perms from everyone Read to FC
3) Grant Bill_Test Modify permissions on the folder c:\test1
4) Map a drive to HOST\share from remote computer as Bill_Test
5) Create a folder called Bill_Test1 in HOST\Share
6) On host, create a file (as Ben) in c:\test1\Bill_Test

Opening the ACL editor and looking at the file's acl does not list
Bill_Test in the ACEs (this is expected), but using the Effective
Permissions tab did show that Bill_Test effectively had Modify
permissions on the file because Bill_Test has FC on the folder where the
file was created.

The real problem is that Bill_Test could modify the file, but was not
listed in the ACL.

I will ping the person who owns the ACL UI today.

In article <OA5KAy$$>,
says...
> Subject: Re: Permissions question
> From: The Rev [MCT] <>
> Newsgroups: microsoft.public.cert.exam.mcse
>
> Security Effective Permissions doesn't take into account any SHARE
> permissions only the NTFS permissions. And if you are looking for creator
> owner permissions then you would need to use CREATOR OWNER in the effective
> permissions user dialog box.
>
>

Share permission are completely irrelevant in this scenario because they
are set to FC.

In article < >,
says...
> I will ping the person who owns the ACL UI today.
>
>

He is out until next week, so I will update this when he returns.

Also, apart from what Ben said, the owner of the file is administrator.

"The Rev [MCT]" wrote:

> Security Effective Permissions doesn't take into account any SHARE
> permissions only the NTFS permissions. And if you are looking for creator
> owner permissions then you would need to use CREATOR OWNER in the effective
> permissions user dialog box.
>
> --
> ..rev.mct.mcngp.44
>
> It is the mark of an educated man to be able to entertain a thought without
> accepting it.
> ~Aristotle
> ..
> "Colin" <> wrote in message
> news:FB75FBCF-DD69-43A4-A2D3-...
> >I have this senario:
> >
> > Create a folder on Windows 2003 Ent. Ed. server, share it as Everyone:
> > Full
> > Access.
> >
> > Security permissions on folder:
> > Administrators: Full Control
> > CREATOR OWNER: Full Control
> > SYSTEM: Full Control
> > Test Group: Read, Create, Write, Append
> >
> > So when a user of Test Group creates a file or folder on the share they
> > become Creator Owner and have full access to that file or folder. But they
> > cannot delete files or folders created by other users.
> >
> > Test
> > 1. Create a file in the folder as domain admin.
> > 2. Map to the share as a user in Test Group and try delete the file. You
> > get
> > permission denied which is expected.
> > 3. As the mapped user, create a folder in the share.
> > 4. Now create a file in that created folder as domain admin.
> > 5. Check permissions on the newly created file. Test Group or user has no
> > delete permissions. Running Effective Permissions against the user also
> > shows
> > no delete permissions.
> > 6. Try delete the file as the user, file is deleted!
> >
> > I assume the file can be deleted because the user is the Creator Owner of
> > the parent folder which propegated Full Access down to the file. But this
> > does not show up on the file's security settings. Why is that?
>
>
>

"Ben Smith" wrote:

> In article < >,
> says...
> > I will ping the person who owns the ACL UI today.
> >
> >
>
> He is out until next week, so I will update this when he returns.
>

Great, thanks Ben.