Security-level permission not working as expected on samba3.5.15

[sandeep nag]

This is experimented on Windows server 2008 R2 Enterprise:
I created a directory C:\share-dir , then given read-only share-level
permissions to testad\sekhar1 user. Now, when I do icacls below is the
output.

*C:\Users\administrator.TESTAD>icacls C:\share-dir*
*C:\share-dir TESTAD\administrator:(OI)(CI)(F)*
*             BUILTIN\Administrators:(OI)(CI)(F)*
*             TESTAD\sekhar1:(OI)(CI)(RX)*
*             NT AUTHORITY\SYSTEM:(OI)(CI)(F)*
*             BUILTIN\Administrators:(OI)(CI)(F)*

*Successfully processed 1 files; Failed processing 0 files*

After that, I have changed the share-level permission on C:\share-dir to
read&write to sekhar1 and then, when I do icacls, below is the output.

*C:\Users\administrator.TESTAD>icacls C:\share-dir*
*C:\share-dir TESTAD\administrator:(OI)(CI)(F)*
*             BUILTIN\Administrators:(OI)(CI)(F)*
*             NT AUTHORITY\SYSTEM:(OI)(CI)(F)*
*             TESTAD\sekhar1:(OI)(CI)(F)*

*Successfully processed 1 files; Failed processing 0 files*

@Richard: 1.Would you like me to perform any other test-case?
                2.Also please tell me, what all requirements to be answered
to upgrade our samba source to higher versions, such that I can get
                    a 'go' from my team. Like set of tests to be passed
etc. Such that I will do them and upgrade the samba.

Thanks,
Sandeep


On Mon, May 26, 2014 at 11:45 PM, Richard Sharpe <
realrichardsharpe at gmail.com> wrote:

> On Mon, May 26, 2014 at 11:02 AM, sandeep nag
> <sandeepnagamalli at gmail.com> wrote:
> > Thank you, for answering my query. Please find my responses inline below:
> >> > 2. On 2008 windows boxes, general behavior on any share folder is: if
> we
> >> > set one of the Share or Security-level permission, other would convert
> >> > to
> >> > the same. i.e we cannot set one of it to read-only and other to
> >> > read&write
> >> > permissions.
> >>
> >> Can you describe exactly what happens to the underlying file-level
> >> permissions when you set a share-level permission?
> >
> > [Sandeep] On 2008 windows box, When I set share-level permission on a
> > shared-folder to read-only, automatically an ACE is getting added to the
> > file-level ACLs list. Now, If I convert the file-level  ACE to
> full-control
> > the the share-level permission is getting converted to read&write
> > automatically.
>
> Can you show me those ACEs? This seems quite an interesting approach
> because it means that setting a share-level permission is modifying
> the underlying file system?
>
> What would happen if the user then further modifies the ACL on the
> directory to include permissions that overlap with those that you
> claim are added by changing the share-level permissions?
>
> You can show this with icacls, for example, before and after changing
> the share-level permissions.
>
> >>
> >>
> >> Does Windows change the underlying file-level permissions? I hope not.
> >>
> >> > 3. Whereas on our samba3.5.15, #2 above is not seen. We are able to
> set
> >>
> >> > Share-level to read&write and Security-levvel permission to read-only.
> >> >         And with such kind of settings, it is allowing to
> create/write a
> >> > file/directory, though there are no enough security-level permissions.
> >> > 4. So, the behavior mentioned in #3 above is not following the rule:
> i.e
> >>
> >> >  ‘The Afffective permission for the user should be the lesser of the
> two
> >> > rights(share-level, security-level)’.
> >> >
> >> > 5. I have tried debugging the issue by placing break points in
> >> > smbd_check_access_rights(), se_accesss_right() and has observed that
> for
> >> > the test-case:
> >> >         share-level read&write permission given for 'everyone' and
> >> > read-only security-level permission given for the share is not working
> >> > as
> >> > expected, i.e the user with just read-only security-level permissions
> >> >         is able to create files and directories in the shared-folder.
> >>
> >> This should not happen. That is because Samba should check the the
> >> share-level permissions before allowing those creates. In particular,
> >> there were issues when creating files/folders, which only checked the
> >> permissions on the parent folder and failed to check the share-level
> >> permissions, I think. There is likely a simple check you can add.
> >>
> >> This is likely because of known bugs. Many of these were fixed in
> >> Samba 3.6.x, so you could look at the Samba 3.6.x code in the same
> >> area.
> >
> > [Sandeep] Yes, As I mentioned in #1 above, there are no issues with
> > Share-level permissions. Issue is seen only in file-level permission.
> > Sure shall I upgrade to 3.6.23 and check the behavior? Is 3.6.23 is good
> in
> > 3.6 series?
>
> Well, there must be share-level permissions problems, because they
> should be applied before the file-level permissions.
>
> Yes, 3.6.23 should have better behavior and in particular includes a
> bunch of fixes for problems we found at another vendor.
>
> However, the group you work for will most likely resist such a move.
>
> --
> Regards,
> Richard Sharpe
> (何以解憂？唯有杜康。--曹操)
>