I asked this question a while ago, but never got any response. Since then, I've researched the problem some more, so I can give a much more concise description of what's happening. I'm mounting the home directories of the users upon login (using pam_mount) from the Windows server. However, none of the users can run X Windows. It says there's a problem with the .Xauthority file. I read that the .Xauthority and the .ICEauthority files can't exist on and SMB share, so I used environment variables and pointed them to /tmp. Now, when the users try to start X (either through the GUI login, or from "startx"), it says the connection is refused by the server. Does anyone have any idea how I can work around this, or how I can fix it and still have the home directories mounted from the Windows server? ____________________________ Shannon Johnson Network Support Specialist / Systems Administrator Dept. of Mechanical and Nuclear Engineering 224 Reber Building University Park, PA 16802 Phone: (814) 865-8267 ____________________________
Shannon Johnson writes: > I'm mounting the home directories of the users upon login (using > pam_mount) from the Windows server. However, none of the users can run X > Windows. It says there's a problem with the .Xauthority file. Would you mind posting the exact error message? I'm just curious, because I don't think there should be any problems with xauth files on SMB. > I read that the .Xauthority and the .ICEauthority files can't exist > on and SMB share, so I used environment variables and pointed them > to /tmp. What mechanism did you use to set the environment variables? PAM? > Now, when the users try to start X (either through the GUI login, > or from "startx"), it says the connection is refused by the > server. Does anyone have any idea how I can work around this, or > how I can fix it and still have the home directories mounted from > the Windows server? If you have only rebound the X authority file for the login process, it's not very likely to work. When the display manager starts, it creates an X authority cookie on the X server, and stores it in an xauth file in a location that depends on the display manager. When the user logs in, the display manager usually merges that cookie into the xauth file in the user's home directory. If you have only set the user's programs to check in /tmp instead, they won't find the file that the display manager created, and thus will not be able to authenticate themselves against the X server. What display manager are you using? Fredrik Tolf
> > Would you mind posting the exact error message? I'm just curious, > because I don't think there should be any problems with xauth files on > SMB. >Sure. From what I understand, the .Xauthority and .ICEauthority use hard links that don't work on any Windows-based filesystem, including SMB. The exact message is: xauth: error in locking authority file /home/users/username/.Xauthority> > What mechanism did you use to set the environment variables? PAM? >I put the following in the user's .bash_profile: XAUTHORITY=/tmp/.Xauthority export XAUTHORITY ICEAUTHORITY=/tmp/.ICEauthority export ICEAUTHORITY> > If you have only rebound the X authority file for the login process, > it's not very likely to work. When the display manager starts, it > creates an X authority cookie on the X server, and stores it in an > xauth file in a location that depends on the display manager. When the > user logs in, the display manager usually merges that cookie into the > xauth file in the user's home directory.That's what I thought... but I read a post somewhere that said if you use the environment variables and point the Xauthority somewhere else (he specifically suggested /tmp), it should work.> > If you have only set the user's programs to check in /tmp instead, > they won't find the file that the display manager created, and thus > will not be able to authenticate themselves against the X server. > > What display manager are you using? > > Fredrik TolfI suppose it's gnome... it's the default under Red Hat 8, 9, and Fedora. I know the theme name is Bluecurve, but I don't know what the actual display manager is.
> > The default under RH (and Fedora) is gdm, yes. > > In that case, edit /etc/X11/gdm/gdm.conf and change the UserAuthDir > line so that it reads "UserAuthDir=/tmp". I think that should make it > work. > > Fredrik TolfI changed that, but I'm getting the same error. The error is: /etc/X11/gdm/PreSession/Default: Registering your session with wtmp and utmp /etc/X11/gdm/PreSession/Default: running /usr/bin/X11/sessreg -a -w /var/log/wtmp -u /var/run/utmp -x "/var/gdm/:0.Xservers" -h "" 01 ":0" "test" Xlib: connection ":0.0" refused by server Xlib: No protocol specified (gnome-session:1617): Gtk-WARNING **: cannot open display: Any ideas? I don't know nearly as much about the X system as I probably should (but I'm learning). Shannon
Shannon Johnson wrote:> > Any ideas? I don't know nearly as much about the X system as > I probably should (but I'm learning). >The ORA book "Linux Security Cookbook" talks about running X apps as root over an SSH link. They suggest using a brief shell script to make sure that the .Xauthority file has the correct ownership. Could this be germane? -wde -- Will Enestvedt UNIX System Administrator Johnson & Wales University -- Providence, RI
> > Well, the "No protocol specified" message refers to the fact that the > client program tried to connect without any authentication (since it > hasn't found the X authority file). > > Did you restart GDM after you changed the setting? > > It's also possible that .bash_profile isn't sourced yet at that > point. Try adding "export XAUTHORITY=/tmp/.Xauthority" to somewhere in > the beginning of /etc/X11/xdm/Xsession and see if that does it. You > could also try using pam_env to add the environment variables. > > Fredrik TolfYes, I rebooted the whole system, just to be safe. I changed the Xsession file, and this is the result (and it's quite long): /etc/X11/gdm/PreSession/Default: Registering your session with wtmp and utmp /etc/X11/gdm/PreSession/Default: running: /usr/bin/X11/sessreg -a -w /var/log/wtmp -u /var/run/utmp -x "/var/gdm/:0.Xservers" -h "" -1 ":0" "test" Xlib: connection to ":0.0" refused by server Xlib: No protocol specified xsetroot: unable to open display ':0' Xlib: connection to ":0.0" refused by server Xlib: No protocol specified xrdb: Can't open display ':0' Xlib: connection to ":0.0" refused by server Xlib: No protocol specified Xmodmap: unable to open display ':0' Xlib: connection to ":0.0" refused by server Xlib: No protocol specified /usr/X11R6/bin/xmbind: Can't open display This is a test line from the .bash_profile file. Xlib: connection to ":0.0" refused by server Xlib: No protocol specified (gnome-session:1604): Gtk-WARNING **: cannot open display: Another relatively minor problem (irritating, if nothing else) is the GUI login screen. It comes up with the "password" blank first, then "username". I put in the username (test, in this case), then after it waits for a second or two, it asks for the password, and I enter it. It rejects it, then prompts me for the username again. This time, when I enter "test", it immediately lets me in (skipping the password blank again). It may or may not have to do with my other problem, but I figured it was something I screwed up in my pam configuration. The system-auth file looks like: Auth required /lib/security/$ISA/pam_env.so Auth required /lib/security/$ISA/pam_mount.so Auth sufficient /lib/security/$ISA/pam_winbind.so use_first_pass Auth sufficient /lib/security/$ISA/pam_unix.so use_first_pass likeauth nullok Account sufficient /lib/security/$ISA/pam_winbind.so Account sufficient /lib/security/$ISA/pam_unix.so Password required /lib/security/$ISA/pam_cracklib.so retry=3 typePassword sufficient /lib/security/$ISA/pam_unix.so nullok use_authtok md5 shadow Password required /lib/security/$ISA/pam_deny.so Session optional /lib/security/$ISA/pam_mount.so Session required /lib/security/$ISA/pam_limits.so Session required /lib/security/$ISA/pam_unix.so>From what I can tell, all the files in /etc/pam.d/ point to, in some wayor another, system-auth. Shannon
I'm just trying to have users be authenticated from an Active Directory server, with all their files on the Windows server. The remote aspect of it can come later, if at all. Shannon ____________________________ Shannon Johnson Network Support Specialist / Systems Administrator Dept. of Mechanical and Nuclear Engineering 224 Reber Building University Park, PA 16802 Phone: (814) 865-8267 ____________________________> -----Original Message----- > From: William Enestvedt [mailto:William.Enestvedt@jwu.edu] > Sent: Thursday, December 11, 2003 11:31 AM > To: samba@lists.samba.org > Subject: RE: [Samba] .Xauthority & SMB > > Shannon Johnson wrote: > > > > Any ideas? I don't know nearly as much about the X system as > > I probably should (but I'm learning). > > > The ORA book "Linux Security Cookbook" talks about running X appsas> root over an SSH link. They suggest using a brief shell script to make > sure that the .Xauthority file has the correct ownership. > Could this be germane? > -wde > -- > Will Enestvedt > UNIX System Administrator > Johnson & Wales University -- Providence, RI > -- > To unsubscribe from this list go to the following URL and read the > instructions: http://lists.samba.org/mailman/listinfo/samba
I may end up just waiting until I get a copy of Red Hat Enterprise Linux 3 before I think too much more about this. I put the "echo $XAUTHORITY >> /tmp/xauth_log" in there, and the file reads "/tmp/.gdmB2gQMM"... however, that file no longer exists. If it helps, when you type in the password first, it immediately rejects it and pops up the username field again. Then, when you put in the username, it waits a second or two before asking for the password... like maybe it's trying to connect to the Windows server. I haven't played around with it too much, as I'm starting to think there's more problems here than I can fix in an afternoon... or a week... ____________________________ Shannon Johnson Network Support Specialist / Systems Administrator Dept. of Mechanical and Nuclear Engineering 224 Reber Building University Park, PA 16802 Phone: (814) 865-8267 ____________________________> -----Original Message----- > From: Fredrik Tolf [mailto:fredrik@dolda2000.com] > Sent: Thursday, December 11, 2003 3:09 PM > To: Shannon Johnson > Cc: Fredrik Tolf; Samba > Subject: RE: [Samba] .Xauthority & SMB > > Shannon Johnson writes: > > I changed the Xsession file, and this is the result (and it's quite > > long): > > > > /etc/X11/gdm/PreSession/Default: Registering your session with wtmpand> > utmp > > /etc/X11/gdm/PreSession/Default: running: /usr/bin/X11/sessreg -a-w> > /var/log/wtmp -u /var/run/utmp -x "/var/gdm/:0.Xservers" -h "" -1":0"> > "test" > > > > Xlib: connection to ":0.0" refused by server > > Xlib: No protocol specified > > > > xsetroot: unable to open display ':0' > > Xlib: connection to ":0.0" refused by server > > Xlib: No protocol specified > > [...] > > Xlib: connection to ":0.0" refused by server > > Xlib: No protocol specified > > > > (gnome-session:1604): Gtk-WARNING **: cannot open display: > > > > That's interesting, and it beats me why I didn't think of that > before. It appears as if the X programs called from Xsession are > (were) able to connect to the X server, which means that XAUTHORITY > has to be set correctly when Xsession starts. Remove the export line > and replace it with "echo $XAUTHORITY >>/tmp/xauth_log" or something > similar to see where gdm has stored the cookie. If the file ends up > empty, that means that the file is in the user's home directory (which > does sound strange, yes), but as far as I know, gdm always sets > XAUTHORITY before forking Xsession, so that shouldn't happen. > > > Another relatively minor problem (irritating, if nothing else) isthe> > GUI login screen. It comes up with the "password" blank first, then > > "username". I put in the username (test, in this case), then afterit> > waits for a second or two, it asks for the password, and I enterit. It> > rejects it, then prompts me for the username again. This time, whenI> > enter "test", it immediately lets me in (skipping the passwordblank> > again). It may or may not have to do with my other problem, but I > > figured it was something I screwed up in my pam configuration. > > That does sound really weird. I thought GDM was hardwired to ask for > the username first. That ruins my idea of how GDM works, so the only > thing I can think of right now to solve it is to download the source > for GDM and debug it. > > Fredrik Tolf