Bug #16072
Unable to fetch logs owned by experiment production accounts, even with a valid Production proxy
0%
Description
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/CN=voms2.fnal.gov
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 15502405.0@fifebatch1.fnal.gov --unzipdir=logs/ --debug
CLIENT_ARGS: {'partial': False, 'format': 'tar', 'acctRole': 'Production', 'list': False, 'destdir': 'logs/', 'jobId': '15502405.0@fifebatch1.fnal.gov', 'debug': True, 'acctGroup': 'darkside', 'user': None, 'timeout': None, 'jobsubServer': 'https://fifebatch.fnal.gov:8443'}
CREDENTIALS : {'key': '/tmp/x509up_u47823', 'cert': '/tmp/x509up_u47823', 'env_key': '/tmp/x509up_u47823', 'proxy': '/tmp/x509up_u47823', 'env_cert': '/tmp/x509up_u47823'}
ERROR:
User kherner is not allowed to read 15502405.0@fifebatch1.fnal.gov, 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.
History
#1 Updated by Dennis Box over 3 years ago
- Target version set to v1.2.5
#2 Updated by Dennis Box over 3 years ago
- Assignee set to Dennis Box
- Target version changed from v1.2.5 to v1.2.6
#3 Updated by Dennis Box about 3 years ago
- Target version changed from v1.2.6 to v1.2.7
#4 Updated by Dennis Box almost 3 years ago
- Target version changed from v1.2.7 to v1.2.8
#5 Updated by Dennis Box over 2 years ago
- Target version changed from v1.2.8 to v1.2.9
#6 Updated by Dennis Box over 2 years ago
- Target version changed from v1.2.9 to v1.2.9.rc_x
#7 Updated by Dennis Box about 2 years ago
- Target version changed from v1.2.9.rc_x to v1.3
#8 Updated by Dennis Box about 2 years 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 about 2 years ago
All of Kens tests and my tests on Kens jobs succeeded, closing the ticket.
#10 Updated by Dennis Box about 2 years ago
- Status changed from Work in progress to Resolved
#11 Updated by Dennis Box over 1 year ago
- Status changed from Resolved to Closed