Bug 870372

Summary: xauth failing on NFSv4 home directory
Product: [Fedora] Fedora Reporter: Ondrej Valousek <ondrejv>
Component: kernelAssignee: Jeff Layton <jlayton>
Status: CLOSED NOTABUG QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: medium Docs Contact:
Priority: unspecified    
Version: 17CC: gansalmon, itamar, jlayton, jonathan, kernel-maint, madhu.chinakonda, steved
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2012-10-29 08:37:40 EDT Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
Attachments:
Description Flags
strace output none

Description Ondrej Valousek 2012-10-26 05:42:49 EDT
File locking does not seem to work on F-17 (+latest updates) on a NFSv4 mounted filesystem (Netapp NAS being NFS server).

Steps to reproduce:
1. mount user home directory via NFSv4 (I used automounter here)
2. try running 'xauth list' command

Actual results:
[ondrejv@dorado3 ~]$ xauth list
<Wait.., wait...>
xauth:  timeout in locking authority file /home/ondrejv/.Xauthority

Desired results:
[ondrejv@draco ~]$ xauth list
ara.prague.s3group.com:1195  MIT-MAGIC-COOKIE-1  716bbc5a5ba2d4b89d91285db99c582d
....

It works fine on RHEL-6, it does not on F-17.
Comment 1 Jeff Layton 2012-10-26 11:21:40 EDT
File locking works just fine for me on f17 (/git is a nfs mount on this machine):

open("/git/ncscope.out", O_RDWR)        = 3
fcntl(3, F_SETLK, {type=F_RDLCK, whence=SEEK_SET, start=0, len=0}) = 0

...perhaps you can do some investigation as to what's going wrong? What's actually failing?
Comment 2 Ondrej Valousek 2012-10-29 06:03:16 EDT
Created attachment 634945 [details]
strace output
Comment 3 Ondrej Valousek 2012-10-29 06:11:17 EDT
Note that I can access (read) the file normally:
[ondrejv@dorado3 ~]$ strings /home/ondrejv/.Xauthority
1195
MIT-MAGIC-COOKIE-1
1002
MIT-MAGIC-COOKIE-1
1002
MIT-MAGIC-COOKIE-1
1000
MIT-MAGIC-COOKIE-1
1000
MIT-MAGIC-COOKIE-1
1001
MIT-MAGIC-COOKIE-1
1001
MIT-MAGIC-COOKIE-1
1012
MIT-MAGIC-COOKIE-1
1012
MIT-MAGIC-COOKIE-1
Comment 4 Jeff Layton 2012-10-29 06:25:53 EDT
It doesn't appear to be a problem with locking, but rather an issue with stat'ing and opening the .Xauthority-c file:

10847 10:57:58.778919 stat("/home/ondrejv/.Xauthority-c", 0x7fff73982850) = -1 EACCES (Permission denied) <0.000073>
10847 10:57:58.779028 open("/home/ondrejv/.Xauthority-c", O_WRONLY|O_CREAT|O_EXCL, 0600) = -1 EACCES (Permission denied) <0.000013>

The fact that the stat is failing is interesting and likely means a problem walking the path down to the file. It could also mean that there is some strange ACL set on this file that the server is enforcing.

A network capture of this might be quite interesting...
Comment 5 Ondrej Valousek 2012-10-29 06:29:31 EDT
Interestingly enough, stat works fine for me:
[ondrejv@dorado3 ~]$ stat /home/ondrejv/.Xauthority
  File: `/home/ondrejv/.Xauthority'
  Size: 464             Blocks: 8          IO Block: 65536  regular file
Device: 29h/41d Inode: 21183271    Links: 1
Access: (0600/-rw-------)  Uid: (14019/ ondrejv)   Gid: (10000/    corp)
Context: system_u:object_r:nfs_t:s0
Access: 2012-10-29 10:46:21.008421000 +0100
Modify: 2012-10-11 11:04:51.393503000 +0200
Change: 2012-10-11 11:04:51.394502000 +0200
 Birth: -

Do you want me to capture tcpdump for you then?
Comment 6 Ondrej Valousek 2012-10-29 06:34:15 EDT
Also question - why is there the '-c' suffix in the open() function argument?
Comment 7 Jeff Layton 2012-10-29 06:55:27 EDT
(In reply to comment #6)
> Do you want me to capture tcpdump for you then?
Sure, it wouldn't hurt...

> Also question - why is there the '-c' suffix in the open() function argument?

No idea -- I assumed that that was just the way that xauth works. Are you also able to stat and open ~/.Xauthority-c ?
Comment 8 Jeff Layton 2012-10-29 06:58:42 EDT
Another thing that might be worth a quick check -- if you have SELinux in enforcing mode, then switching it to permissive temporarily and redoing the test might also be worthwhile. e.g.:

    # setenforce 0

...and then try it again.
Comment 9 Ondrej Valousek 2012-10-29 08:04:54 EDT
That was it! After disabling SELinux, xauth works fine.
Perhaps we shell keep the case open so that the default SELinux policy can be modified?

Ondrej
Comment 10 Jeff Layton 2012-10-29 08:08:55 EDT
Ok, one more question. What's the output of this command?

    $ getsebool use_nfs_home_dirs

...if that boolean is "off" then you'll probably want to turn it on and test again. If it's on, then we'll switch this over to a selinux-policy bug...
Comment 11 Ondrej Valousek 2012-10-29 08:37:40 EDT
Ok, use_nfs_home_dirs SELinux boolean was set to off. After enabling it, the problem vanished.
Sorry for the noise, closing the case - but please take a look at another bug #871024 that I have just opened as it is closely related.

Thanks.
Ondrej