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

[Richard Sharpe]

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
(何以解憂？唯有杜康。--曹操)