Bug 128683 - Samba 3.0.4-6.3E breaks "Valid users" share definition access control method
Samba 3.0.4-6.3E breaks "Valid users" share definition access control method
Status: CLOSED WONTFIX
Product: Red Hat Enterprise Linux 3
Classification: Red Hat
Component: samba (Show other bugs)
3.0
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Simo Sorce
David Lawrence
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2004-07-27 18:12 EDT by Tom Sightler
Modified: 2007-11-30 17:07 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-10-19 15:22:04 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)

  None (edit)
Description Tom Sightler 2004-07-27 18:12:14 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7)
Gecko/20040626 Firefox/0.9.1

Description of problem:
The recently released samba errata packages (3.0.4-6.3E) seem to break
group based share definition access control.

We have a share that is configured as follows:

[transfer]
        comment = Unix/Windows Transfer
        path = /mnt/misfiles/linux/transfer
        public = yes
        writeable = yes
        guest ok = no
        nt acl support = yes
        oplocks = no
        level2 oplocks = no
        force create mode = 0775
        force directory mode = 2775
        force group = +transfer
        valid users = @transfer

The "transfer" group is a standard unix group that has as members
several standard NIS users and several winbind mapped users.  With the
samba-3.0.2-6.3E packages this has the effect of allowing access to
the share only to those who are members of the group.

After upgrading to samba-3.0.4-6.3E no users are allowed access this
share, even local unix users that are members of the group (so this is
not a winbind problem).  We do have other "open" shares on the server
that continue to work fine allowing both local and winbind users access.

Based on available documentation I believe that the 3.0.2-6.3E
behaviour was correct (I'm pretty confident it behaved this way in the
previous samba 3.0.0-14 as well, we have used this config for quite a
while now).  For now we have reverted to the previous version.



Version-Release number of selected component (if applicable):
samba-3.0.4-6.3E

How reproducible:
Always

Steps to Reproduce:
1. Create a share using a group in the "Valid Users=" option for
access control to a share
2. Attempt access the share with a user account who is a member of the
appropriate group

    

Actual Results:  Access is denied.  No password combination that we
have found will allow access to the share.

Expected Results:  Access to the share should be allowed for users who
are members of the group.


Additional info:
Comment 1 Tom Sightler 2004-08-01 13:07:01 EDT
I've checked this against the stock Samba distribution and it appears 
to be a change in bahaviour between 3.0.2 and 3.0.3.  Since I can 
reproduce it with stock code I will probably file a bug with the 
Samba team as well.

One noted difference in the log files, most of the users in the 
"transfer" group are winbind mapped users and we use the "winbind use 
default domain" option.  With 3.0.2 it would check their name against 
the group as "testuser" but with 3.0.3+ it checks it as 
"DOMAIN\testuser" which is certainly a major behaviour change, 
however, adding the users to the group with this combined name still 
doesn't solve the problem however.

Tom
Comment 2 RHEL Product and Program Management 2007-10-19 15:22:04 EDT
This bug is filed against RHEL 3, which is in maintenance phase.
During the maintenance phase, only security errata and select mission
critical bug fixes will be released for enterprise products. Since
this bug does not meet that criteria, it is now being closed.
 
For more information of the RHEL errata support policy, please visit:
http://www.redhat.com/security/updates/errata/
 
If you feel this bug is indeed mission critical, please contact your
support representative. You may be asked to provide detailed
information on how this bug is affecting you.

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