Ambiguity in curl token upload without explicity DN mapping in grid-mapfile

1

Dear Elvin

I see the following behavior on eos 5.1.9
when my DN is mapped ( to some account) and
I use x509 to create a eos macaroon

I got 230426 16:50:54 time=1682520654.844667 func=IdMap                    level=INFO  logid=static.............................. unit=mgm@grid23.lal.in2p3.fr:1094 tid=00007f6c877fb700 source=Mapping:1000                   tident= sec=(null) uid=99 gid=99 name=- geo="" sec.prot=https sec.name="" sec.host="[::ffff:134.158.72.161]" sec.vorg="" sec.grps="" sec.role="" sec.info="" sec.app="http" sec.tident="http" vid.uid=5000 vid.gid=5005
230426 16:50:54 time=1682520654.848706 func=IdMap                    level=INFO  logid=static.............................. unit=mgm@grid23.lal.in2p3.fr:1094 tid=00007f6c877fb700 source=Mapping:1000                   tident= sec=(null) uid=99 gid=99 name=- geo="" sec.prot=https sec.name="dtes" sec.host="[::ffff:134.158.72.161]" sec.vorg="" sec.grps="" sec.role="" sec.info="" sec.app="http" sec.tident="http" vid.uid=5000 vid.gid=5005
230426 16:50:54 time=1682520654.850977 func=open                     level=INFO  logid=bf199928-e441-11ed-a6d8-44a8423af928 unit=mgm@grid23.lal.in2p3.fr:1094 tid=00007f6c877fb700 source=XrdMgmOfsFile:3210             tident=http sec=https uid=5000 gid=5005 name=dtes geo="" path=/eos/grif/dteam/alekos open:rt=2.14 io:bw=inf io:sched=0 io:type=buffered io:prio=default io:redirect=grid21.lal.in2p3.fr:11001 duration=2.162ms timing=IdMap=0.066ms fid::fetch=0.067ms fid::fetched=0.000ms authorize=0.124ms authorized=0.007ms path-computed=0.003ms container::fetched=0.154ms write::begin=0.120ms write::end=0.947ms Policy::begin=0.003ms Policy::end=0.115ms Scheduler::FilePlacement=0.253ms Scheduler::FilePlaced=0.078ms end=0.225ms Open=2.162ms

and the curl upload works fine , with

export DST=https://grid23.lal.in2p3.fr:11000/eos/grif/dteam/alekos
export TDST=$(curl --silent --cert /tmp/x509up_u$(id -u) --key /tmp/x509up_u$(id -u) --cacert /tmp/x509up_u$(id -u) --capath /etc/grid-security/certificates -X POST -H 'Content-Type: application/macaroon-request' -d '{"caveats": ["activity:UPLOAD,DELETE,DOWNLOAD,UPLOAD,LIST,MANAGE"], "validity": "PT3000M"}' "$DST" | jq -r '.macaroon')
 
 echo $TDST
 curl -L -v --capath /etc/grid-security/certificates -H "Authorization: Bearer $TDST" $DST.$RANDOM --upload /etc/hosts

when I do not map explicitly the my DN in gridmap-file and left the VID to make the mapping ( which is also configured in the first case).
I got

Secgsi GRIDmap file: /etc/grid-security/grid-mapfile
Secgsi GRIDmap option: trymap,usedn
Secgsi GRIDmap cache entries expiration (secs): 1
=====> sec.protocol gsi -crl:0 -cert:/etc/grid-security/daemon/hostcert.pem -key:/etc/grid-security/daemon/hostkey.pem -gridmap:/etc/grid-security/grid-mapfile -d:2 -gmapopt:11 -vomsat:1 -moninfo:1 -gmapto:1
=====> http.gridmap /etc/grid-security/grid-mapfile
230426 16:52:14 time=1682520734.060240 func=IdMap level=INFO logid=static… unit=mgm@grid23.lal.in2p3.fr:1094 tid=00007fa2c8c08700 source=Mapping:1000 tident= sec=(null) uid=99 gid=99 name=- geo=“” sec.prot=https sec.name=“” sec.host=“[::ffff:134.158.72.161]” sec.vorg=“” sec.grps=“” sec.role=“” sec.info=“” sec.app=“http” sec.tident=“http” vid.uid=99 vid.gid=99
230426 16:52:14 time=1682520734.064782 func=IdMap level=INFO logid=static… unit=mgm@grid23.lal.in2p3.fr:1094 tid=00007fa2c8c08700 source=Mapping:1000 tident= sec=(null) uid=99 gid=99 name=- geo=“” sec.prot=https sec.name=“99” sec.host=“[::ffff:134.158.72.161]” sec.vorg=“” sec.grps=“” sec.role=“” sec.info=“” sec.app=“http” sec.tident=“http” vid.uid=99 vid.gid=99
230426 17:00:01 time=1682521201.697935 func=IdMap level=INFO logid=static… unit=mgm@grid23.lal.in2p3.fr:1094 tid=00007fa2c8c08700 source=Mapping:1000 tident= sec=(null) uid=99 gid=99 name=- geo=“” sec.prot=sss sec.name=“daemon” sec.host=“localhost” sec.vorg=“” sec.grps=“daemon” sec.role=“” sec.info=“” sec.app=“” sec.tident=“root.2259243:465@localhost” vid.uid=0 vid.gid=0


and the  upload is failed 


 I have :

> case a) 230426 16:50:54 2251795 sysMacaroonGen: ID=51665f92-325d-476d-be8e-9522ffc30cb1, resource=/eos/grif/dteam/alekos, protocol=gsi, name=dtes, host=[::ffff:134.158.72.161], vorg=dteam, role=NULL, groups=/dteam, endorsements=/dteam/Role=NULL/Capability=NULL, base_activities=activity:READ_METADATA,UPLOAD,DOWNLOAD,DELETE,MANAGE,UPDATE_METADATA,LIST, user_caveat=activity:UPLOAD,DELETE,DOWNLOAD,UPLOAD,LIST,MANAGE, expires=2023-04-27T14:50:54Z

and 
`case b) 230426 16:52:13 2253305 sysMacaroonGen: ID=cfad8c1d-df97-4662-bbbb-2b688b32c13f, resource=/eos/grif/dteam/alekos, protocol=gsi, name=719340ae.0, host=[::ffff:134.158.72.161], vorg=dteam, role=NULL, groups=/dteam, endorsements=/dteam/Role=NULL/Capability=NULL, base_activities=activity:READ_METADATA,UPLOAD,DOWNLOAD,DELETE,MANAGE,UPDATE_METADATA,LIST, user_caveat=activity:UPLOAD,DELETE,DOWNLOAD,UPLOAD,LIST,MANAGE, expires=2023-04-27T14:52:13Z`

eos vid ls |grep dteam
voms:“/dteam:”:gid => dteam
voms:“/dteam:”:uid => dte000


thus we could not remove completely the grid-mapfile for some DN as the upload with macaroon failed
this behaviour is lack of functionality or bug ?
thank you in advance
best
e.v.
2

Hi Emmanouil,

Yes, indeed this type of interaction does not behave as one might expect and the explanation for it is that the EOS code is not involved in the initial issuing of the macaroon token. Therefore, the gsi plugin from the XRootD framework will perform the extraction of the information (and possibly the grid-mapping part) and will then directly send this to the macaroon library which will use this info to populate the identity of the client inside the token.

In the first case it is properly set to name=dtes which is the result of the the grid-map file and in the second one is set to name=719340ae.0 which is just a hash of the DN.

The eos vid mapping is never called as this happens further down the stack, but I will look into the possibility of calling this before passing the mapped identity to the macaroon library.

Cheers,
Elvin

3

hello Elvin
thank you for your reply

for the record, in the same frame
the gfal-copy in TPC push mode with eos (under question) as destination
is affected by the aboves
TPC pull mode is working
FYI
best
e.v.

4

Hi Emmanouil,

This issue is now tracked in this ticket [1] and I’ve fixed it for the next eos release 5.1.17.
The new version will probably be released next week. Thanks for bringing this to our attention!

Cheers,
Elvin

[1] https://its.cern.ch/jira/browse/EOS-5641