I have test kernels on my people page with the updated CIFS code. Testing now,
but it looks good so far. I'll post the patches to the BZ as well...

Created attachment 290996 [details]
tarball containing stock cifs-1.50c

Tarball containing stock 1.50c code from Steve French's backported kernel
series. Pulled from here:

http://pserver.samba.org/samba/ftp/cifs-cvs/

Created attachment 290997 [details]
tarball containing patches to bring 4.6ish kernels up to 1.50cRH

The update is 19 patches, so I'm not going to attach them individually. This
tarball contains the set. The result builds with a few warnings, which seem to
be innocuous. I've also sent a few of these patches to Steve F. to fix a few
spots where older kernels of RHEL4's vintage were not accounted for.

Cursory testing looks good so far -- no failures with connectathon. Testing
with fsstress now...

Test kernels with the above patchset are available on my peoplepage:

http://people.redhat.com/jlayton/

This request was evaluated by Red Hat Product Management for inclusion in a Red
Hat Enterprise Linux maintenance release.  Product Management has requested
further review of this request by Red Hat Engineering, for potential
inclusion in a Red Hat Enterprise Linux Update release for currently deployed
products.  This request is not yet committed for inclusion in an Update
release.

*** Bug 427346 has been marked as a duplicate of this bug. ***

*** Bug 426080 has been marked as a duplicate of this bug. ***

*** Bug 349291 has been marked as a duplicate of this bug. ***

Committed in 68.11. RPMS are available at http://people.redhat.com/vgoyal/rhel4/.

*** Bug 440082 has been marked as a duplicate of this bug. ***

*** Bug 442446 has been marked as a duplicate of this bug. ***

Hi David,

IBM is clamoring fairly loudly that they need a fix for this problem
immediately.  Now that we've isolated the problem (with Jeff Layton's
help) and verified the issue is already fixed with updates/fixes made to
the CIFS module prior to U7, the customer is asking for an accelerated
fix.

I imagine we've probably released something as a hotfix kernel already
for another customer.  Per Jeff it would need to be -68.11 or newer to
have the fix for this issue.  The nightly U7 on curly (20080416.0a) has
2.6.9-69.EL.

--vince



Internal Status set to 'Waiting on Engineering'

This event sent from IssueTracker by vincew 
 issue 173383

I appreciate the efforts of the engineering team on this.  I think we may
be talking about two different issues here.  The posix mkdir code that was
added and sold to the customer as a "fix" for their problem, is only a
fix in that it avoids the section of the code that causes the problem.  

When CIFS sends the SMBmkdir to the server, Samba is creating the file
with the permissions that it should have.  The setgid bit is getting set
correctly.  The problem is that afterwards, CIFS is sending another packet
overwriting those permissions with new ones that do not take setgid into
account.  There are two solutions, either don't send the additional
packet that alters the permissions (which may break the umask related
functions of the client), or have the cifs_mkdir code take the setgid bit
into consideration when overwriting the permissions.  

With the posix mkdir code included in the hotfix, as long as unix
extensions are turned off and the server supports posix operations, then
the code above does not get used.  The posix mkdir code runs instead. 
But, if either of those things are not true (which for this customer it
was the fact that Samba was at 3.0.10 instead of 3.0.25b and therefore
lacked posix support) it will fall back to the old incorrect behavior.  

Inode caching on the client should not impact this from what I can tell.

With all that said, this may all be academic.  The customer has decided to
not disable unix extensions (and thus live without case sensitivity).  With
unix extensions enabled, the problem is resolved.  As a result, they are
looking to close their call and thus I must close this one.  Since I do
see a defect here, I wouldn't mind following any bugzillas that are open
on the subject.  Was a bugzilla ever opened for this issue (not the inode
caching issue)?

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

This event sent from IssueTracker by jwest 
 issue 173383

correction:  paragraph 3 of the last update should read "... unix
extensions are turned ON and the ..."


This event sent from IssueTracker by jwest 
 issue 173383

Couple of things:

From what I can tell is doesn't take a Samba server that is all that old
to not have posix support.  In this customer's case, they have RHEL 4 U6
machines running Samba 3.0.10, which doesn't support posix mkdir (at
least in my testing).

With unix extensions disabled, the routine falls through and from what I
can tell will always reset the permissions after the SMBmkdir.  The
cifs_mkdir() code reads:


                if (cifs_sb->tcon->ses->capabilities & CAP_UNIX)
                        if (cifs_sb->mnt_cifs_flags & CIFS_MOUNT_SET_UID)
{
                                CIFSSMBUnixSetPerms(xid, pTcon,
full_path,
...
                        } else {
                                CIFSSMBUnixSetPerms(xid, pTcon,
full_path,
...
                        }
                else {
...
                        if(direntry->d_inode) {
                                direntry->d_inode->i_mode = mode;
...
                        }
                }

This looks like it will still overwrite the local inode's mode even with
UNIX extensions disabled.  This looks incorrect.  If the server doesn't
support posix operations, the mkdir code should still honor setgid on
directories.  

In this customer's case, they have decided to not disable unix
extensions, but they are now forced to upgrade their servers to the latest
Samba in order to get posix support.  Shouldn't the client be set up to
work regardless of the server's release level?


This event sent from IssueTracker by jwest 
 issue 173383

Sounds reasonable and we may actually have enough info to try to make the client
set this correctly. That said, it's not going to happen in 4.7. The fix will
need to go upstream first. I suggest opening a new BZ for it.

adding to RHEL4.7 release notes under "Kernel-Related Updates":

<quote>
CIFS is now updated to version 1.50c. This update applies several enhancements
and bug fixes, including the capability to mount OS/2 shares (even when
CONFIG_CIFS_WEAK_PW_HASH was not set during module compilation).
</quote>

please advise if any revisions are required, particularly if any other CIFS
updates need to be noted as well.

The part in parenthesis doesn't make much sense. Turning on
CONFIG_CIFS_WEAK_PW_HASH is required to make OS/2 shares work. I suggest we
leave that part out. How about:

<quote>
CIFS is now updated to version 1.50c. This update applies several enhancements
and bug fixes, including the capability to mount shares from older servers such
as OS/2.
</quote>

thanks JEff. revised accordingly. 

Hi,

the RHEL4.7 release notes deadline is on June 17, 2008 (Tuesday). they will
undergo a final proofread before being dropped to translation, at which point no
further additions or revisions will be entertained.

a mockup of the RHEL4.7 release notes can be viewed here:
http://intranet.corp.redhat.com/ic/intranet/RHEL4u7relnotesmockup.html

please use the aforementioned link to verify if your bugzilla is already in the
release notes (if it needs to be). each item in the release notes contains a
link to its original bug; as such, you can search through the release notes by
bug number.

Cheers,
Don

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/RHSA-2008-0665.html