Bug 870372
| Summary: | xauth failing on NFSv4 home directory | ||||||
|---|---|---|---|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Ondrej Valousek <ondrejv> | ||||
| Component: | kernel | Assignee: | Jeff Layton <jlayton> | ||||
| Status: | CLOSED NOTABUG | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||
| Severity: | medium | Docs Contact: | |||||
| Priority: | unspecified | ||||||
| Version: | 17 | CC: | 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 12:37:40 UTC | Type: | Bug | ||||
| 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
Ondrej Valousek
2012-10-26 09:42:49 UTC
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?
Created attachment 634945 [details]
strace output
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 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...
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? Also question - why is there the '-c' suffix in the open() function argument? (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 ? 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.
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 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...
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 |