Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.
For bugs related to Red Hat Enterprise Linux 5 product line. The current stable release is 5.10. For Red Hat Enterprise Linux 6 and above, please visit Red Hat JIRA https://issues.redhat.com/secure/CreateIssue!default.jspa?pid=12332745 to report new issues.

Bug 619112

Summary: CIFS mount to samba3x share shows differing ownership on sequential stat() calls to same file
Product: Red Hat Enterprise Linux 5 Reporter: Justin Payne <jpayne>
Component: kernelAssignee: Jeff Layton <jlayton>
Status: CLOSED ERRATA QA Contact: yanfu,wang <yanwang>
Severity: high Docs Contact:
Priority: high    
Version: 5.5CC: eguan, jentrena, kzhang, smarkovi, steved, tao, yanwang
Target Milestone: rc   
Target Release: ---   
Hardware: All   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2011-01-13 21:45:49 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
text tcpdump
none
verbose cifs data
none
binary tcpdump taken from samba server in the lab
none
binary tcpdump taken from CIFS client
none
patch -- make cifs always override uid/gid none

Description Justin Payne 2010-07-28 15:36:21 UTC 
Customer has a Samba share on machine A which allow guest access and forces user, 
group, creation and security mode.

  create mask = 0770
  security mask = 0770
  directory mask = 0770
  directory security mask = 0770
  force create mode = 0770
  force security mode = 0770
  force directory mode = 0770
  force directory security mode = 0770
  guest ok = yes
  force user = devsamba
  force group = samba1

Customer accesses this share from machine B, mounting the share as the 'null' user 
(sec=none) and forcing the user and group owners of the files on the client server.

sec=none,uid=bdeadm,gid=sapsys

>    Observed behavior:

When the customer accesses this share as a standard user, sometimes he gets EACCES 
errors trying to modify existing files.
Even a simple 'touch' command on a non existing file is able to create the file, 
but fails setting the last access and modification times ('utimes' command):

25058 open("test1.txt", O_WRONLY|O_CREAT|O_NOCTTY|O_NONBLOCK, 0666) = 0
25058 utimes("/proc/self/fd/0", NULL)   = -1 EACCES (Permission denied)
25058 utimes("test1.txt", NULL)         = -1 EACCES (Permission denied)
25058 close(0)

The customer has written a test utility that places the following calls:

r = open(av[1], O_RDWR|O_CREAT|O_EXCL, 0666);
r = close(r);

r = stat(av[1], &st_buf);

r = open(av[1], O_WRONLY|O_CREAT|O_TRUNC, 0666);

sleep(1);

r = stat(av[1], &st_buf);

r = open(av[1], O_WRONLY|O_CREAT|O_TRUNC, 0666);

On a non previously existing file, the first and third 'open' calls succeed.
The second open call fails with EACCES (Permission denied).

Furthermore, the first 'stat' call returns different uid and gid from the second 
'stat' call.

When the customer accesses this share as the root user, the issue is not
reproducible.

I'm not able to reproduce the issue with Fedora 13 as a CIFS client 
(2.6.33.6-147.fc13.x86_64).

>    Desired behavior:

The customer should be able to modify the files on the Samba share as a standard,
allowed user at anytime, even inmediately after the creation of the file.

Steps to reproduce:

10.33.8.156                Samba server
10.33.8.157                CIFS client with the Samba share mounted.

Login to the CIFS client VM.

# su - bdeadm
$ cd /mnt/qassamba

$ touch testfile

or

$ /usr/local/bin/testutil testfile

(source code for /usr/local/bin/testutil is in /root/testutil.c).
Comment 1 Justin Payne 2010-07-28 15:41:52 UTC 
Created attachment 435052 [details]
text tcpdump

Best tcpdump I have until I can gather a binary dump.
Comment 2 Justin Payne 2010-07-28 15:44:35 UTC 
Created attachment 435056 [details]
verbose cifs data

dmesg output after touching said file as user bdeadm
Comment 3 Justin Payne 2010-07-28 15:54:22 UTC 
Created attachment 435059 [details]
binary tcpdump taken from samba server in the lab

Binary tcpdump taken from samba server in the lab. The following actions were performed as user bdeadm on the client:

# su - bdeadm
$ cd /mnt/qassamba

$ touch testfile
$ stat testfile
Comment 4 Justin Payne 2010-07-28 15:56:20 UTC 
Created attachment 435061 [details]
binary tcpdump taken from CIFS client

Binary tcpdump taken from CIFS client in the lab. The following actions were
performed as user bdeadm:

# su - bdeadm
$ cd /mnt/qassamba

$ touch testfile
$ stat testfile
Comment 5 Jeff Layton 2010-07-28 16:03:44 UTC 
> Binary tcpdump taken from CIFS client in the lab. The following actions were
> performed as user bdeadm:
> 
> # su - bdeadm
> $ cd /mnt/qassamba
> 
> $ touch testfile
> $ stat testfile    

That doesn't look like the same reproducer that the customer was using. Were you able to reproduce the problem with that?
Comment 6 Julio Entrena Perez 2010-07-28 16:25:47 UTC 
The reproducer is in /usr/local/bin/testutil.
The source code of the reproducer is in /root/testutil.c .
Comment 7 Jeff Layton 2010-07-28 17:00:05 UTC 
Testing on my own machine...it looks like the ownership of the file (inode->i_uid) is changing. Here are 3 consecutive calls to cifs_permission:

 fs/cifs/cifsfs.c: cifs_permission: mask=0x2 inode=ffff81003ebf2090 owner=15512 fsuid=50000
 fs/cifs/cifsfs.c: cifs_permission: mask=0x1 inode=ffff81003ebf29d0 owner=50000 fsuid=50000
 fs/cifs/cifsfs.c: cifs_permission: mask=0x2 inode=ffff81003ebf2090 owner=15512 fsuid=50000

...how it's changing like this is not 100% clear to me yet.
Comment 8 Jeff Layton 2010-07-28 17:09:28 UTC 
Ahh, nm those are two different inodes. I think I understand the problem now though:

posix_fill_in_inode has a force_uid_gid flag and that's being set in some cases. That prevents the uid= parm from taking effect here. When I clear that flag it works as expected. That should also fix the problems with stat() returning different info.

I forget however, why that flag is there in the first place, so I'll need to do a little archaeology to determine what the proper fix is.
Comment 9 Jeff Layton 2010-07-28 17:53:31 UTC 
Created attachment 435096 [details]
patch -- make cifs always override uid/gid

Here's a proposed patch for RHEL5

This patch seems to fix the "touch" testcase for me. I assume it'll probably fix the other testcase too. Could you test it and report back to me whether it does?
Comment 10 Issue Tracker 2010-07-29 01:08:14 UTC 
Event posted on 07-28-2010 09:08pm EDT by jpayne

Hi,

Please have the customer test the packages found at:

http://people.redhat.com/jpayne/1093523/

Thanks,

Justin

Internal Status set to 'Waiting on Support'

This event sent from IssueTracker by jpayne 
 issue 1093523
Comment 11 Issue Tracker 2010-08-03 12:00:34 UTC 
Event posted on 13:00:33, 3rd Aug, 2010 BST by jentrena

Hi Justin,

The customer reports that the test package solves the bug for them.

Thank you.
Julio

Internal Status set to 'Waiting on SEG'

This event sent from IssueTracker by jentrena 
 issue 1093523
Comment 12 Julio Entrena Perez 2010-08-03 12:03:46 UTC 
The test packages solves the bug.
Comment 14 RHEL Program Management 2010-08-03 12:29:28 UTC 
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.
Comment 17 Jarod Wilson 2010-08-31 01:18:08 UTC 
in kernel-2.6.18-214.el5
You can download this test kernel from http://people.redhat.com/jwilson/el5

Detailed testing feedback is always welcomed.
Comment 19 Eryu Guan 2010-11-24 06:07:18 UTC 
Reproduced on -194 kernel(both server and client)
(To simplify setup, I did setenforce 0)
[tester@dhcp-65-135 ~]$ id
uid=501(tester) gid=501(tester) groups=501(tester) context=root:system_r:unconfined_t:SystemLow-SystemHigh
[tester@dhcp-65-135 ~]$ mount | grep cifs
//sun-x4440-01.rhts.eng.bos.redhat.com/public on /mnt type cifs (rw,mand)
[tester@dhcp-65-135 ~]$ ./testutil /mnt/testfile
Open1: 3 0
Close: 0 0
Start: 0 0 u:500 g:500 mode:0100770
Open2: -1 13
Start: 0 13 u:501 g:501 mode:0100770
Open3: 3 13
[tester@dhcp-65-135 ~]$

Verified on -231 kernel(both server and client)
[tester@dhcp-65-135 ~]$ id
uid=501(tester) gid=501(tester) groups=501(tester) context=root:system_r:unconfined_t:SystemLow-SystemHigh
[tester@dhcp-65-135 ~]$ mount | grep cifs
//sun-x4440-01.rhts.eng.bos.redhat.com/public on /mnt type cifs (rw,mand)
[tester@dhcp-65-135 ~]$ ./testutil /mnt/testfile
Open1: 3 0
Close: 0 0
Start: 0 0 u:501 g:501 mode:0100770
Open2: 3 0        <=======  The second open succeed and ownership didn't change
Start: 0 0 u:501 g:501 mode:0100770
Open3: 4 0
[tester@dhcp-65-135 ~]$
Comment 21 errata-xmlrpc 2011-01-13 21:45:49 UTC 
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-2011-0017.html