Bug 481046 - [RHEL5.3] Unable to remove inherited ACLs in Samba 3.0.32
[RHEL5.3] Unable to remove inherited ACLs in Samba 3.0.32
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 5
Classification: Red Hat
Component: samba (Show other bugs)
5.3
All Linux
urgent Severity urgent
: rc
: ---
Assigned To: Simo Sorce
BaseOS QE
: Regression, ZStream
Depends On: 471292 471605
Blocks: 501513
  Show dependency treegraph
 
Reported: 2009-01-21 16:40 EST by Jeremy West
Modified: 2016-06-17 17:08 EDT (History)
9 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Due to the method in which the Microsoft® Excel program saves files, in certain corner cases the access control list (ACL) inheritance rules could have been interpreted in the wrong order, and the owner of a file saved by Excel could have ended up losing access to that file. These updated packages include an adjusted fix for this problem which fixes the ACL inheritance so that saving an Excel file does not cause the owner to change.
Story Points: ---
Clone Of: 471605
Environment:
Last Closed: 2009-09-02 07:54:32 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Fixes the excel regression (12.22 KB, patch)
2009-01-26 16:33 EST, Simo Sorce
no flags Details | Diff

  None (edit)
Description Jeremy West 2009-01-21 16:40:19 EST
+++ This bug was initially created as a clone of Bug #471605 +++

+++ This bug was initially created as a clone of Bug #471292 +++

Escalated to Bugzilla from IssueTracker

--- Additional comment from tao@redhat.com on 2008-11-12 16:14:07 EDT ---

Customer Name:   IBM
Customer RH Login:   lurf_pcsv

Description of problem:
Customer upgraded from 3.0.25b to 3.0.32 (as per RHIT 238404).  Now he cannot remove inherited ACLs from child directories as he could before.

How reproducible:
I was able to reproduce this issue in my lab 100% of the time.

Steps to Reproduce:
1. Install Samba 3.0.32 and set up a share with ACL support.
2. Browse to the share using a Windows client.
3. Create a directory and edit the permissions to provide full access to some other user.
4. Create a subdirectory under that and note that the permissions for that other user were inherited (as expected).
5. Go to the advanced tab and click to remove the permissions for that other user and click "Apply"

Actual results:
The permissions will be removed, but then immediately show up again.

Expected results:
As in previous versions of Samba, including 3.0.25b, the permissions should be removed when the "Remove" button is pressed.  The checkbox for "Inherit from parent the permission entries that apply to
child objects. Include these with entries explicitly defined here" used to be checked and only after clearing it could inherited permissions be removed.  In 3.0.32, that box is already cleared, but the permissions can't be removed anyway.

Additional info:  
The customer reported this issue to the Samba bugzilla for the Samba 3.2 tree at https://bugzilla.samba.org/show_bug.cgi?id=5873 and it was also reported for the Samba 3.0 tree at https://bugzilla.samba.org/show_bug.cgi?id=5877.  No work appears to have been done on the bugs so far.  I will attach a sosreport for the system as well as a screen shot of the Windows dialog box just to level set.
This event sent from IssueTracker by vincew  [Support Engineering Group]
 issue 238852

--- Additional comment from tao@redhat.com on 2008-11-12 16:14:09 EDT ---

File uploaded: Samba_screenshot_GUI.rtf

This event sent from IssueTracker by vincew  [Support Engineering Group]
 issue 238852
it_file 172778

--- Additional comment from tao@redhat.com on 2008-11-12 16:14:10 EDT ---

File uploaded: sosreport_rchs9bld-480003.tar.bz2

This event sent from IssueTracker by vincew  [Support Engineering Group]
 issue 238852
it_file 172779

--- Additional comment from tao@redhat.com on 2008-11-12 16:14:11 EDT ---

SEG,

Escalating this up as it's blocking and urgent need for a hotfix on IT
238404.  IBM has outlined the problem very well and given reproduction
steps (see ticket description). We need to decide how much of an impact
this will have on the samba 3.0.32 packages we plan to release with RHEL
4.8.

Thanks
Jeremy West


Issue escalated to Support Engineering Group by: jwest.
jwest assigned to issue for IBM-IGS.
Internal Status set to 'Waiting on SEG'
Status set to: Waiting on Tech

This event sent from IssueTracker by vincew  [Support Engineering Group]
 issue 238852

--- Additional comment from tao@redhat.com on 2008-11-12 16:14:13 EDT ---

Adam,

I've escalated this ticket to engineering so that they can review this and
determine whether or not it would block us giving you hotfix packages for
IT 238404.

Thanks for reporting this.
Jeremy


This event sent from IssueTracker by vincew  [Support Engineering Group]
 issue 238852

--- Additional comment from vincew@redhat.com on 2008-11-12 16:29:04 EDT ---

SUMMARY FOR ENGINEERING

Customer (IBM) has tested our 3.0.32-0.el4.11 samba packages and verified they correct the problem with joining domains.  However they also found that they cannot remove inherited ACL's on directories in shares from Windows clients now, which worked for them in 3.0.25b, so we will have a regression in Samba functionality if this issue doesn't get resolved before we release 3.0.32 in the next update.

Customer has filed bugs upstream as well, against the 3.0 and 3.2 branches.

Setting the 4.8? and blocker? flag due to $ABOVE.  I know we don't have much time, but we should probably try to fix this if we can before releasing 4.8 (and 5.3).

--vince

--- Additional comment from vincew@redhat.com on 2008-11-12 16:37:37 EDT ---

PS: there is a hotfix request (also by IBM) for 3.0.32 packages to be provided before 4.8 release to solve the domain join problems they have seen.  Do you think we should wait to try to send this hotfix request up through our SEG management team until we know what can be done on this BZ?  Or plan to deal with this BZ aftewards?

Thanks,
Vince

--- Additional comment from lsmid@redhat.com on 2008-11-13 06:30:43 EDT ---

Approved for RHEL 4.8.

--- Additional comment from tao@redhat.com on 2008-11-13 13:06:20 EDT ---

Jeremy,

I'm not 100% sure this is what IBM is seeing but it sounds pretty similar.
 I say I'm not 100% sure because the smb.conf man page in 3.0.32 says this
option was deprecated in 3.0.23 and IBM mentioned they could perform the
operations in question on 3.0.25b without problem.  However this still may
be worth a try since the option was re-introduced in 3.0.31 and its default
setting is off.

(from the man page):

       acl group control (S)

           In a POSIX filesystem, only the owner of a file or directory
and the
           superuser can modify the permissions and ACLs on a file. If
this
           parameter is set, then Samba overrides this restriction, and
also
           allows the primary group owner of a file or directory to modify
the
           permissions and ACLs on that file.

           On a Windows server, groups may be the owner of a file or
directory -
           thus allowing anyone in that group to modify the permissions on
it.
           This allows the delegation of security controls on a point in
the
           filesystem to the group owner of a directory and anything below
it
           also owned by that group. This means there are multiple people
with
           permissions to modify ACLs on a file or directory, easing
           managability.

           This parameter allows Samba to also permit delegation of the
control
           over a point in the exported directory hierarchy in much the
same way
           as Windows. This allows all members of a UNIX group to control
the
           permissions on a file or directory they have group ownership
on.

           This parameter is best used with the inherit owner option and
also on
           on a share containing directories with the UNIX setgid bit set
on
           them, which causes new files and directories created within it
to
           inherit the group ownership from the containing directory.

           This is parameter has been was deprecated in Samba 3.0.23, but
           re-activated in Samba 3.0.31 and above, as it now only
controls
           permission changes if the user is in the owning primary group.
It is
           now no longer equivalent to the dos filemode option.

           Default: acl group control = no



What I'd like to see if they can test is to set 'acl group control = yes'
in the share definition of a share they can test on, as well as enabling
'inherit owner' and setting the setgid bit as the above says this works
best with -- then restart samba, and see if having this on helps them at
all.

They should probably also test with 'dos filemode' enabled, though I'd say
test adding that after testing with 'acl group control' first.

Not saying there isn't a bug in 3.0.32 - there may well be - but since
this seems related and is an option added back in for 3.0.32, it probably
bears trying this out in case this is the cause.

Thanks
Vince

Internal Status set to 'Waiting on Support'

This event sent from IssueTracker by vincew 
 issue 238852

--- Additional comment from tao@redhat.com on 2008-11-13 16:03:43 EDT ---

Unfortunately the suggestions did not resolve the problem.  My first test
was to set "acl group control = yes" and "inherit owner = yes" in
samba.conf.  In a second test, I also set "dos filemode = yes".  In both
cases, I was still able to reproduce the problem in my lab.  

I'm afraid I don't understand when or how I would set the setgid bit on
the directory since I am doing the entire re-creation from the Windows
side.  There is no point where I am on the Linux side setting permission
bits.  Using the Windows client, I just create a folder, add full control
to an additional userid, create a subdirectory under it and try to remove
that userid from the ACL on the new subdirectory.  Is there a way to set
the setgid from the Windows side? 

By the way, I think a key to this problem may be the checkbox for 

"Inherit from parent the permission entries that apply to child objects.
Include these with entries explicitly defined here".  

In Samba 3.0.25b when using the smb.conf provided, that checkbox is
checked by default.  The change to the ACL of the subdirectory is only
possible once that checkbox is cleared (otherwise the "Remove" button is
greyed out).  With Samba 3.0.32, that checkbox is cleared from the start,
and the "Remove" button doesn't seem to work correctly.  This can't be a
coincidence.

Internal Status set to 'Waiting on Support'
Status set to: Waiting on Tech

This event sent from IssueTracker by bottchen 
 issue 238852

--- Additional comment from ssorce@redhat.com on 2008-11-13 16:31:05 EDT ---

Upstream is aware of the problem and is actively working to find a proper solution.
https://bugzilla.samba.org/show_bug.cgi?id=5873 has a preliminary patch

--- Additional comment from tao@redhat.com on 2008-11-17 03:13:30 EDT ---

linked from IT236903.


This event sent from IssueTracker by mmatsuya 
 issue 236903

--- Additional comment from dpal@redhat.com on 2008-12-04 13:32:27 EDT ---

Asking for QE and dev acks

--- Additional comment from dpal@redhat.com on 2008-12-04 13:33:12 EDT ---

Giving dev ack.

--- Additional comment from syeghiay@redhat.com on 2008-12-04 14:58:51 EDT ---

From kwirth: yes, we need this as dmitri indicated. 

Approved 5.3 esc blocker-rc for Snapshot 6.
Please rebuild/respin by Dec 10 5PM Eastern.

--- Additional comment from gdeschner@redhat.com on 2008-12-09 11:01:23 EDT ---

preliminary patch commited.

--- Additional comment from errata-xmlrpc@redhat.com on 2008-12-09 12:00:23 EDT ---

Bug report changed to ON_QA status by Errata System.
A QE request has been submitted for advisory RHBA-2009:8117-02
http://errata.devel.redhat.com/errata/show/7809

--- Additional comment from errata-xmlrpc@redhat.com on 2008-12-11 17:05:07 EDT ---

Bug report changed from ON_QA to VERIFIED status by the Errata System: 
Advisory RHBA-2009:8117-04: 
http://errata.devel.redhat.com/errata/show/7809

--- Additional comment from errata-xmlrpc@redhat.com on 2008-12-16 06:08:17 EDT ---

Bug report changed to RELEASE_PENDING status by Errata System.
Advisory RHBA-2009:8117-04 has been changed to HOLD status.
http://errata.devel.redhat.com/errata/show/7809

--- Additional comment from errata-xmlrpc@redhat.com on 2009-01-20 16:47:35 EDT ---

An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHBA-2009-0180.html
Comment 2 RHEL Product and Program Management 2009-01-21 16:56:47 EST
This bugzilla has Keywords: Regression.  

Since no regressions are allowed between releases, 
it is also being proposed as a blocker for this release.  

Please resolve ASAP.
Comment 3 Simo Sorce 2009-01-26 16:30:37 EST
Final patch that resolves also the excel regression has been developed in collaboration with upstream.
Comment 4 Simo Sorce 2009-01-26 16:33:39 EST
Created attachment 330028 [details]
Fixes the excel regression

This patch reorders the way ownership is changed within the ACL code.
The ownership of a file was changed in the wrong order, also the chown pathg was wrong in force user ownership in some corner cases.

This patch has been developed together with upstream and backported to RHE5 version.
Comment 16 Douglas Silas 2009-06-29 10:17:13 EDT
Release note added. If any revisions are required, please set the 
"requires_release_notes" flag to "?" and edit the "Release Notes" field accordingly.
All revisions will be proofread by the Engineering Content Services team.

New Contents:
Due to the method in which the Microsoft® Excel program saves files, in certain corner cases the access control list (ACL) inheritance rules could have been interpreted in the wrong order, and the owner of a file saved by Excel could have ended up losing access to that file. These updated packages include an adjusted fix for this problem which fixes the ACL inheritance so that saving an Excel file does not cause the owner to change.
Comment 18 errata-xmlrpc 2009-09-02 07:54:32 EDT
An advisory has been issued which should help the problem
described in this bug report. This report is therefore being
closed with a resolution of ERRATA. For more information
on therefore solution and/or where to find the updated files,
please follow the link below. You may reopen this bug report
if the solution does not work for you.

http://rhn.redhat.com/errata/RHBA-2009-1416.html

Note You need to log in before you can comment on or make changes to this bug.