Bug 4116 - globus_module_activate( GLOBUS_GRAM_CLIENT_MODULE ) behaves differently for ENOENT and EACCES
: globus_module_activate( GLOBUS_GRAM_CLIENT_MODULE ) behaves differently for E...
Status: RESOLVED FIXED
: GSI C
Credentials and Proxies
: 4.0.1
: PC Linux
: P3 normal
: 4.0.6
Assigned To:
:
:
:
:
  Show dependency treegraph
 
Reported: 2005-12-19 14:31 by
Modified: 2008-08-11 15:08 (History)


Attachments


Note

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


Description From 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 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 2007-12-03 12:17:14 -------
Committed a patch to this to 4.0 branch and trunk.