Bug 3214 – Backend of GT4 GridFTPd should ignore ~/.globus/certificates

Bug 3214 - Backend of GT4 GridFTPd should ignore ~/.globus/certificates

Summary:

Backend of GT4 GridFTPd should ignore ~/.globus/certificates

Status:	NEW

Product:	GridFTP
Component:	GridFTP
Version:	4.0.0
Platform:	All All

Importance:	P3 normal
Target Milestone:	---
Assigned To:	Mike Link

URL:
Keywords:

Depends on:
Blocks:
	Show dependency tree / graph

Reported:	2005-04-22 15:55 by Von Welch
Modified:	2005-05-13 09:52 (History)

Attachments
log4j.logger.globus set to DEBUG (42.63 KB, text/plain) 2005-04-22 16:01, Jay Alameda	Details
Add an attachment (proposed patch, testcase, etc.)

Note

You need to log in before you can comment on or make changes to this bug.

Description From Von Welch 2005-04-22 15:55:06

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
certificate.

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.

------- Comment #1 From Von Welch 2005-04-22 15:57:32 -------

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.

------- Comment #2 From Jay Alameda 2005-04-22 16:01:05 -------

Created an attachment (id=586) [details]
log4j.logger.globus set to DEBUG

here is the log4j output from jglobus 1.2

------- Comment #3 From Mike Link 2005-04-22 16:38:02 -------

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 
frontend->backend connection.

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?

------- Comment #4 From Sam Meder 2005-04-22 17:04:21 -------

That should work if X509_CERT_DIR survives the setuid call.

/Sam

------- Comment #5 From Von Welch 2005-04-28 09:53:34 -------

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.

------- Comment #6 From Olle Mulmo 2005-05-13 09:52:21 -------

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.