Bugzilla – Bug 3214
Backend of GT4 GridFTPd should ignore ~/.globus/certificates
Last modified: 2005-05-13 09:52:21
You need to
before you can comment on or make changes to this bug.
The backend part of the new gridftpd server will use ~/.globus/certificates if
it is present in the target user's home directory on the server machine. This
creates some very hard-to-debug situations and I see no positive side to it.
This causes very strange behavior if the user doesn't have the CA certificate
for the host certificate of the server in their certificates directory since you
then get a authentication failure on the client side about authentication
failure on the gridftpd server regarding a missing CA certificate for the host
Here is what we see:
On the NCSA TG machine Jay creates an NCSA-based proxy and then runs
a set of gridftp tests against GT2, GT 3.9.5 and 4.0rc1 gridftp
servers that JP has set up at UC.
If he has ~alameda/.globus/certificates on the UC machine moved aside,
all works well.
If he has ~alameda/.globus/certificates on the UC machine, it fails to the 3.9.5
and 4.0rc1 server. He gets a error about a DOE Grids signing policy not being
found. Note the only DOE Grids certificate in play is the host cert on the UC
machine. If he moves the DOE Grids CA certs into his .globus/certificates
directory, everything works.
I don't think there are any security vulnerabilities here, since I believe this
only gets uses to authenticate the front part of the gridftpd, but it sure
creates a hard-to-debug situation.
Plus it's different behavior from prior gridftpds.
Actually thinking more about this, I'm not sure if it's the backend or the
frontend. If it's the backend, how are we getting an error message.
In a nutshell, I'm not sure what exactly is going on, but some part of the
gridftpd is paying attention to ~/.globus/certificates and it shouldn't be.
Created an attachment (id=586) [details]
log4j.logger.globus set to DEBUG
here is the log4j output from jglobus 1.2
Yeah, its the frontend that is looking at ~/.globus/. Whats happening is that
the server is started as root, does the client auth* as root, and then setuids
to the user. The ipc connection to the backend is then made as the user, so
that is why it is looking at the users .globus dir. Which is also why this was
never an issue with other gridftpd's, they never had a gsi authenticated
I'm not sure of the order of where the signing policy is looked for, but does
it not even look in /etc/grid-security/certificates if ~/.globus/certificates
exists (it appears so)? What if you set X509_CERT_DIR in the frontend's env?
That should work if X509_CERT_DIR survives the setuid call.
Just to clarify on this, this is a behavior change from pre-4.0 gridftpd that
users with ~/.globus/certificates will see. If we can't fix it (Sam says it will
be difficult), it should at least be documented.
Also related (but probably a separate bug): If the user's home directory is in
AFS, the ~/.globus/certificates check will always fail (~/.globus exists but
cannot be read without the necessary AFS tokens).
This happens on our tape robot frontend machine so people are not supposed to
write in their home directories but under /hsm. Setting X509_CERT_DIR does the
trick but I agree with Von that this needs to be documented.