Bug 4116 – globus_module_activate( GLOBUS_GRAM_CLIENT_MODULE ) behaves differently for ENOENT and EACCES

Bug 4116 - globus_module_activate( GLOBUS_GRAM_CLIENT_MODULE ) behaves differently for ENOENT and EACCES

Summary:

globus_module_activate( GLOBUS_GRAM_CLIENT_MODULE ) behaves differently for E...

Status:	RESOLVED FIXED

Product:	GSI C
Component:	Credentials and Proxies
Version:	4.0.1
Platform:	PC Linux

Importance:	P3 normal
Target Milestone:	4.0.6
Assigned To:	Joe Bester

URL:
Keywords:

Depends on:
Blocks:
	Show dependency tree / graph

Reported:	2005-12-19 14:31 by Burt Holzman
Modified:	2008-08-11 15:08 (History)

Attachments
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 Burt Holzman 2005-12-19 14:31:24

I hope this is direct enough -- this was discovered when using GAHP from the
condor folks.

When searching for CA certificates,

globus_module_activate( GLOBUS_GRAM_CLIENT_MODULE )

by default looks in ~/.globus/certifactes.

If it doesn't exist (ENOENT), it goes looking elsewhere (/etc/grid-security,
where they are located on our site) and works properly.  If it can't access it
at all (EACCES), it instead errors out with an error #7 (Failed to activate
Globus 'modules').  This behavior seems a little inconsistent -- when an item in
the middle of a search path returns EACCES, I would expect the call to continue
to the next item rather than return an error.

This is a problem at FNAL where .globus can be in AFS and users may disallow
system:anyuser from read and lookup access.

------- Comment #1 From Joe Bester 2006-11-01 10:32:33 -------

The issue exists in the globus_gsi_sysconfig_get_cert_dir_unix() which treats
does not exist errors differently than other types of errors. There's probably
no reason to fail if a dir is unreadable differently than not existing.

------- Comment #2 From Joe Bester 2007-12-03 12:17:14 -------

Committed a patch to this to 4.0 branch and trunk.