Are you using pam_afs_session? We've just discovered that when that is
enabled in the su stack, becoming root takes a very long time, whether
or not you have set the minimum_uid or not. The simple solution is to
not run pam_afs_session in the 'su' stack.
I ran into this a while ago. The
On Wed, 17 Mar 2010, emat...@yahoo.com wrote:
Also, when the su command finally completes, I noticed this:
[emat...@aerogold ~]$ su
Password:
X11 connection rejected because of wrong authentication.
xhost: unable to open display localhost:10.0
The xhost thing is happening because I am
/afs/psi.ch/user/g/gsell/.Xauthority
Trust me, you don't want your XAUTHORITY information in AFS. Put it in
/tmp/ or some other place where it does not go unecrypted over the
network. Yes, you will have to modify the gdm/xdm config on your
desktop and all X11 forwardig services (sshd) to do
On Wed, Mar 17, 2010 at 9:25 PM, emat...@yahoo.com wrote:
Well, there's nothing in /var/log/messages either. As for checking the PAM
configuration for su, can you elaborate? I'm a beginner at this, so you may
have to provide details.
You probably need to adjust your syslog settings, most
I'm not sure I see the value of putting a file that's part of a distributed
network filesystem in a local directory... is that what you are suggesting?
What if you log into a different machine to access your AFS space?
thanks,
eric
--- On Thu, 3/18/10, Harald Barth h...@kth.se wrote:
From:
This is what I see in /var/log/debug:
Mar 18 08:19:55 aerogold su: (pam_afs_session): pam_sm_open_session: entry (0x0)
Mar 18 08:19:55 aerogold su: (pam_afs_session): skipping tokens, no Kerberos
ticket cache
Mar 18 08:19:55 aerogold su: (pam_afs_session): pam_sm_open_session: exit
(success)
Just as another data point, when I try to su from a local account, I experience
no delay but /var/log/debug gives exactly the same output.
And I'm still getting:
X11 connection rejected because of wrong authentication.
xhost: unable to open display localhost:10.0
only for the case of
I'm not sure I see the value of putting a file that's part of a
distributed network filesystem in a local directory.
First: The .Xauthority file is only used locally on your machine, why
would you need it in AFS?
Second: If we now can agree that .Xauthority does not need to be in
AFS, why not
Just as another data point, when I try to su from a local account,
I experience no delay but /var/log/debug gives exactly the same output.
Humor me for a minute.
There should be in one of your pam config files a module called pam_xauth
or something similar. Try commenting it out and see if that
On Mar 18, 2010, at 1:59 PM, Harald Barth wrote:
I'm not sure I see the value of putting a file that's part of a
distributed network filesystem in a local directory.
First: The .Xauthority file is only used locally on your machine, why
would you need it in AFS?
You don't need it on AFS.
I see what you are saying, but how would you handle a scenario with thousands
of people (university students) accessing hundreds of computers in labs all
over campus which they are not responsible for and cannot be bothered to
manage? Is there a way of automatically forcing .XAuthority to
Interesting-
There is no pam_xauth file, but there was instances of
session optional pam_xauth.so
in su, config-util,run_init,selinux-polgengui,system-config-selinux, and
yumex-yum-backend, all in /etc/pam.d.
When I comment the version in su, the delay went away!
I still get:
X11
On Mar 18, 2010, at 2:17 PM, emat...@yahoo.com wrote:
I see what you are saying, but how would you handle a scenario with thousands
of people (university students) accessing hundreds of computers in labs all
over campus which they are not responsible for and cannot be bothered to
manage?
Ok, one other data point- I should have mentioned in the very beginning that
I'm actually logging into the machine in question remotely, then issuing the su
command. This seems to make a difference. While I THOUGHT the problem
occurred either way, now I'm finding that if I actually sit down
Ok, one other data point- I should have mentioned in the very beginning that
I'm actually logging into the machine in question remotely, then issuing
the su command. This seems to make a difference. While I THOUGHT the
problem occurred either way, now I'm finding that if I actually sit down
at
On Thu, Mar 18, 2010 at 1:41 PM, emat...@yahoo.com wrote:
Ok, one other data point- I should have mentioned in the very beginning that
I'm actually logging into the machine in question remotely, then issuing the
su command. This seems to make a difference. While I THOUGHT the problem
No, I do not. And that's with or without the
session optionalpam_xauth.so
in /etc/pam.d/su, and does not matter if I'm at the machine or logged in
remotely.
thanks,
eric
--- On Thu, 3/18/10, Ken Hornstein k...@cmf.nrl.navy.mil wrote:
From: Ken Hornstein
No, I do not.
So, let me understand you _completely_.
When pam_xauth.so is in /etc/pam.d/su, and when you log in on the console:
- tokens shows AFS tokens _before_ you su.
- There is no delay for su.
- tokens shows no AFS tokens _after_ you su.
When pam_xauth.so is in /etc/pam.d/su, and when
You are correct in your assumptions. Regarding XAUTHORITY (with pam_xauth in
su):
logging in at the machine, this is what I find:
before su:
[emat...@aerogold ~]$ echo $XAUTHORITY
/var/run/gdm/auth-for-ematlis-s3Q2Bx/database
after su:
[r...@aerogold ematlis]# echo $XAUTHORITY
You are correct in your assumptions. Regarding XAUTHORITY (with pam_xauth
in su):
logging in at the machine, this is what I find:
before su:
[emat...@aerogold ~]$ echo $XAUTHORITY
/var/run/gdm/auth-for-ematlis-s3Q2Bx/database
Ah-HA!
Okay, that explains it. When you log in locally (I assume)
Ken, thanks for all your help (and the same to the others who have also
responded). I'm grateful to be sure.
Since I'm a total newbie at this, I'll either have to look up and decipher what
you've suggested (I don't even know what PAGs are!) or rely on somebody else to
chip in with
On Thu, 18 Mar 2010, Harald Barth wrote:
I'm not sure I see the value of putting a file that's part of a
distributed network filesystem in a local directory.
Afs home directories and .Xauthority is a pretty good way to let
everyone on your machine read all your keystrokes.
Anything that
-Original Message-
From: openafs-info-ad...@openafs.org [mailto:openafs-info-ad...@openafs.org]
On Behalf Of Ken
Hornstein
- Assuming you're using ssh (I am guessing that you are), convince sshd
to write your Xauthority information somewhere else, like a file
in /tmp
- Assuming you're using ssh (I am guessing that you are), convince sshd
to write your Xauthority information somewhere else, like a file
in /tmp (and make sure your XAUTHORITY environment variable is correct).
I would guess this is possible, but I don't know if there's an easy
way to
I created a file ~/.ssh/rc as per your suggestion in the machine that I am
logging into (aerogold in this case). Logging in gives me this:
[mat...@quadzilla ~]$ ssh -Y emat...@aerogold
emat...@aerogold's password:
Last login: Thu Mar 18 14:24:37 2010 from quadzilla.aero.nd.edu
X11 connection
I created a file ~/.ssh/rc as per your suggestion in the machine that I am
logging into (aerogold in this case). Logging in gives me this:
[mat...@quadzilla ~]$ ssh -Y emat...@aerogold
emat...@aerogold's password:
Last login: Thu Mar 18 14:24:37 2010 from quadzilla.aero.nd.edu
X11
I'm sorry David, it's not clear to me what I should put in rc. Can you send
the entire contents?
thanks,
eric
--- On Thu, 3/18/10, David S. Goldberg d...@mitre.org wrote:
From: David S. Goldberg d...@mitre.org
Subject: Re: [OpenAFS] significant delay for afs user to login as root via su
David S. Goldberg wrote:
- Assuming you're using ssh (I am guessing that you are), convince sshd
to write your Xauthority information somewhere else, like a file
in /tmp (and make sure your XAUTHORITY environment variable is correct).
I would guess this is possible, but I don't know if
emat...@yahoo.com writes:
Just as another data point, when I try to su from a local account, I
experience no delay but /var/log/debug gives exactly the same output.
And I'm still getting:
X11 connection rejected because of wrong authentication.
xhost: unable to open display localhost:10.0
Carson Gaspar wrote:
else
# X11UseLocalhost=no
echo add $DISPLAY $proto $cookie
fi | /usr/X11/bin/xauth -q - 12
fi
You'll also need to change the xauth path to match your local machine,
or set PATH, or use the prayer method that xauth is in your default PATH.
--
You don't need it on AFS. It's just the default location where
pam_xauth stores it and no option is available to change this. The
only solution (I see) is to write a xauth-wrapper, which can be
passed to the pam_xauth via xauthpath=/path/to/xauth.
I have a patched sshd to do the right thing
Hello-
I have noticed a significant delay (30 seconds or more) for a user logged in
through an AFS account to open the root account via the command su. This
delay does not happen for a local account. I'm not sure where to start looking
for this one. Any ideas?
Thanks,
eric
On 17 Mar 2010, at 20:24, emat...@yahoo.com wrote:
I have noticed a significant delay (30 seconds or more) for a user
logged in through an AFS account to open the root account via the
command su. This delay does not happen for a local account. I'm
not sure where to start looking for this
Simon Wilkinson s...@inf.ed.ac.uk writes:
On 17 Mar 2010, at 20:24, emat...@yahoo.com wrote:
I have noticed a significant delay (30 seconds or more) for a user
logged in through an AFS account to open the root account via the
command su. This delay does not happen for a local account. I'm
Yes, I am using pam_afs_session. You've lost me about not using it in the su
stack. Can you elaborate? Here's my system-auth-ac if it helps...
authrequired pam_env.so
authsufficientpam_fprintd.so
authsufficientpam_unix.so nullok try_first_pass
auth
I added debug to the end of this line in /etc/pam.d/system-auth-ac:
auth [default=done] pam_afs_session.so program=/usr/bin/aklog debug
However, /var/log/secure does not show any more information that normal. Do I
need to restart some service to activate this change?
Also, when the su
emat...@yahoo.com writes:
I added debug to the end of this line in /etc/pam.d/system-auth-ac:
auth [default=done] pam_afs_session.so program=/usr/bin/aklog debug
However, /var/log/secure does not show any more information that normal.
Do I need to restart some service to activate this
I added debug to the session stack as so:
session required pam_afs_session.so program=/usr/bin/aklog debug
However, logging in via su only produces this in /var/log/secure:
Mar 17 17:22:25 aerogold su: pam_unix(su:session): session opened for user root
by ematlis(uid=86261)
thoughts?
emat...@yahoo.com writes:
I added debug to the session stack as so:
session required pam_afs_session.so program=/usr/bin/aklog debug
However, logging in via su only produces this in /var/log/secure:
Mar 17 17:22:25 aerogold su: pam_unix(su:session): session opened for user
root
Well, there's nothing in /var/log/messages either. As for checking the PAM
configuration for su, can you elaborate? I'm a beginner at this, so you may
have to provide details.
Thanks,
eric
--- On Wed, 3/17/10, Russ Allbery r...@stanford.edu wrote:
From: Russ Allbery r...@stanford.edu
As another data point, I tried logging in via sudo -i instead of su. Here's
what happened in /var/log/secure:
Mar 17 17:36:38 aerogold sudo: pam_unix(sudo-i:auth): authentication failure;
logname=ematlis uid=0 euid=0 tty=/dev/pts/0 ruser=ematlis
rhost=aerogold.aero.nd.edu user=ematlis
Mar 17
emat...@yahoo.com writes:
Well, there's nothing in /var/log/messages either. As for checking the
PAM configuration for su, can you elaborate? I'm a beginner at this, so
you may have to provide details.
I don't know what version of Linux you're using, but as a general rule of
thumb, look in
emat...@yahoo.com writes:
As another data point, I tried logging in via sudo -i instead of su.
Here's what happened in /var/log/secure:
Mar 17 17:36:38 aerogold sudo: pam_unix(sudo-i:auth): authentication failure;
logname=ematlis uid=0 euid=0 tty=/dev/pts/0 ruser=ematlis
My version of Linux is Fedora 12 x86_64. Here is my /etc/pam.d/su:
#%PAM-1.0
authsufficient pam_rootok.so
# Uncomment the following line to implicitly trust users in the wheel group.
#auth sufficient pam_wheel.so trust use_uid
# Uncomment the following line to
On 17 Mar 2010, at 21:52, emat...@yahoo.com wrote:
Since pam_afs_session.so is not listed, I'd guess you are right, and that is
not the source of the delay.
system-auth is listed, which means that it uses the contents of the system auth
stack that you have already posted. So, I suspect you
emat...@yahoo.com writes:
My version of Linux is Fedora 12 x86_64. Here is my /etc/pam.d/su:
#%PAM-1.0
auth sufficient pam_rootok.so
# Uncomment the following line to implicitly trust users in the wheel group.
#auth sufficient pam_wheel.so trust use_uid
#
Simon Wilkinson s...@inf.ed.ac.uk writes:
On 17 Mar 2010, at 21:52, emat...@yahoo.com wrote:
Since pam_afs_session.so is not listed, I'd guess you are right, and
that is not the source of the delay.
system-auth is listed, which means that it uses the contents of the
system auth stack that
On Mar 17, 2010, at 10:52 PM, emat...@yahoo.com wrote:
My version of Linux is Fedora 12 x86_64. Here is my /etc/pam.d/su:
#%PAM-1.0
auth sufficient pam_rootok.so
# Uncomment the following line to implicitly trust users in the wheel group.
#auth sufficient
Actually, I am calling xhost, not xauth:
xhost +si:localuser:lp
sorry about the confusion.
eric
--- On Wed, 3/17/10, Simon Wilkinson s...@inf.ed.ac.uk wrote:
From: Simon Wilkinson s...@inf.ed.ac.uk
Subject: Re: [OpenAFS] significant delay for afs user to login as root via su
To:
49 matches
Mail list logo
