Bug #16072

Unable to fetch logs owned by experiment production accounts, even with a valid Production proxy

Added by Kenneth Herner almost 3 years ago. Updated 4 months ago.

Target version:
Start date:
Due date:
% Done:


Estimated time:
First Occurred:
Occurs In:


If I have a valid proxy with the Production role and I try to fetch a log file owned by the experiment production account, I get an authorization error. Here is an example:

$ voms-proxy-info -all
subject : /DC=org/DC=cilogon/C=US/O=Fermi National Accelerator Laboratory/OU=People/CN=Kenneth Herner/CN=UID:kherner/CN=2344230668
issuer : /DC=org/DC=cilogon/C=US/O=Fermi National Accelerator Laboratory/OU=People/CN=Kenneth Herner/CN=UID:kherner
identity : /DC=org/DC=cilogon/C=US/O=Fermi National Accelerator Laboratory/OU=People/CN=Kenneth Herner/CN=UID:kherner
type : RFC compliant proxy
strength : 1024 bits
path : /tmp/x509up_u47823
timeleft : 11:59:58
key usage : Digital Signature, Key Encipherment, Data Encipherment === VO fermilab extension information ===
VO : fermilab
subject : /DC=org/DC=cilogon/C=US/O=Fermi National Accelerator Laboratory/OU=People/CN=Kenneth Herner/CN=UID:kherner
issuer : /DC=org/DC=opensciencegrid/O=Open Science Grid/OU=Services/
attribute : /fermilab/darkside/Role=Production/Capability=NULL
(other attributes omitted)

Note the production role. Then I try to fetch the log:

]$ jobsub_fetchlog -G darkside --role=Production -J --unzipdir=logs/ --debug
CLIENT_ARGS: {'partial': False, 'format': 'tar', 'acctRole': 'Production', 'list': False, 'destdir': 'logs/', 'jobId': '', 'debug': True, 'acctGroup': 'darkside', 'user': None, 'timeout': None, 'jobsubServer': ''}
CREDENTIALS : {'key': '/tmp/x509up_u47823', 'cert': '/tmp/x509up_u47823', 'env_key': '/tmp/x509up_u47823', 'proxy': '/tmp/x509up_u47823', 'env_cert': '/tmp/x509up_u47823'}


User kherner is not allowed to read, owned by darksidepro. This is configurable, if you believe this to be in error please open a service desk ticket.

So jobsub is still mapping me as kherner even though GUMS would map this to darksidepro (I assume because of the UID: part in the DN.) However, in the production case we need the GUMS mapping, since we want to allow for the case in which one user submits a production job but another user, also with the production role, wants to be able to access it.

I note that there is a workaround where using a managed proxy, you get mapped properly. However I think we need to fix this case.

Finally there is one other problem: setting aside the UID: and production role issue for a moment, since I am a global superuser, I claim that I should have been able to download the log anyway. Clearly, though, the global superuser bit is not working for these production accounts.


#1 Updated by Dennis Box over 2 years ago

  • Target version set to v1.2.5

#2 Updated by Dennis Box over 2 years ago

  • Assignee set to Dennis Box
  • Target version changed from v1.2.5 to v1.2.6

#3 Updated by Dennis Box about 2 years ago

  • Target version changed from v1.2.6 to v1.2.7

#4 Updated by Dennis Box almost 2 years ago

  • Target version changed from v1.2.7 to v1.2.8

#5 Updated by Dennis Box over 1 year ago

  • Target version changed from v1.2.8 to v1.2.9

#6 Updated by Dennis Box about 1 year ago

  • Target version changed from v1.2.9 to v1.2.9.rc_x

#7 Updated by Dennis Box 12 months ago

  • Target version changed from v1.2.9.rc_x to v1.3

#8 Updated by Dennis Box 11 months ago

  • Status changed from New to Work in progress

I think this has been resolved by #22039. Shreyas and I tested all the combinations we could think of for multiple users in a group with Production role doing things to each others jobs.

As a final test, I asked Ken so submit a darksidePro job to a server where I am global superuser.

I do not have Production role for darkside, I will test what I can do to this job as a superuser.

#9 Updated by Dennis Box 11 months ago

All of Kens tests and my tests on Kens jobs succeeded, closing the ticket.

#10 Updated by Dennis Box 11 months ago

  • Status changed from Work in progress to Resolved

#11 Updated by Dennis Box 4 months ago

  • Status changed from Resolved to Closed

Also available in: Atom PDF