setting gplazma.roles.admin-gid to anything other than 0 break roles

[alrossi]

we set it to 1000 on our testbed and found that dcache-view could not find any roles to assert do not yet know if this is a dcache-view issue or a gplazma module issue.

[paulmillar]

Could you copy (the salient parts of) your gPlazma configuration?

[alrossi]

in dcache.conf:

gplazma.roles.admin-gid=1000

in dcache.kpwd:

version 2.1 mapping "/DC=org/DC=opensciencegrid/O=Open Science Grid/OU=People/CN=Albert Louis Rossi 1714" arossi mapping "arossi@FNAL.GOV" arossi

login arossi read-write 8773 1530,1000 / /pnfs/fs/usr/test/arossi / /DC=org/DC=opensciencegrid/O=Open Science Grid/OU=People/CN=Albert Louis Rossi 1714 arossi@FNAL.GOV

passwd arossi ba22a191 read-write 8773 1530,1000 / /pnfs/fs/usr/test/arossi

does not work

but

gplazma.roles.admin-gid=0

in dcache.kpwd:

version 2.1 mapping "/DC=org/DC=opensciencegrid/O=Open Science Grid/OU=People/CN=Albert Louis Rossi 1714" arossi mapping "arossi@FNAL.GOV" arossi

login arossi read-write 8773 1530,0 / /pnfs/fs/usr/test/arossi / /DC=org/DC=opensciencegrid/O=Open Science Grid/OU=People/CN=Albert Louis Rossi 1714 arossi@FNAL.GOV

passwd arossi ba22a191 read-write 8773 1530,0 / /pnfs/fs/usr/test/arossi

does.

gplazma.conf in both cases:

auth optional voms
auth optional x509

map optional authzdb session optional authzdb session required roles

auth sufficient kpwd "kpwd=/etc/dcache/dcache.kpwd" map sufficient kpwd "kpwd=/etc/dcache/dcache.kpwd" session sufficient kpwd "kpwd=/etc/dcache/dcache.kpwd"

in dcache-view, in the first case, logging in always gives me "authentication successful, but no roles to assert":

[alrossi]

dcache-view is master. dcache is 4.2.14

[paulmillar]

Could you use curl to issue a GET request to the user introspection endpoint with dCache configured to accept gid 1000 as role admin and copy the response?

Here's an example:

paul@celebrimbor:~$ curl -s -E /tmp/x509up_u1000 --capath /etc/grid-security/certificates https://prometheus.desy.de:3880/api/v1/user | jq .
{
  "status": "AUTHENTICATED",
  "uid": 2002,
  "gids": [
    2002,
    0
  ],
  "unassertedRoles": [
    "admin"
  ],
  "username": "paul",
  "email": [
    "paul.millar@desy.de"
  ],
  "homeDirectory": "/Users/paul",
  "rootDirectory": "/"
}
paul@celebrimbor:~$ 

[alrossi]

OK I'll try this. Ignore the previous comment. It just takes a little time for the snapshot to refresh in frontend. Repeating the CURL command after about 15 seconds, the transfers show up.

So the only real issue here to address is the role definition one (why anything other than 0 doesn't work).

[alrossi]

Paul, I get no output:

[arossi@otfrid scripts]$ curl -s -E /tmp/x509up_u8773 --capath /etc/grid-security/certificates https://fndcatemp1.fnal.gov:3880/api/v1/user . [arossi@otfrid scripts]$

Am I missing something? (jq does not exist on my node ... what is it?)

[alrossi]

if I do this in the browser (https://fndcatemp1.fnal.gov:3880/api/v1/user):

{ "status" : "AUTHENTICATED", "uid" : 8773, "gids" : [ 1530, 1000 ], "username" : "arossi", "email" : [ "arossi@fnal.gov" ], "homeDirectory" : "/", "rootDirectory" : "/pnfs/fs/usr/test/arossi" }

[paulmillar]

You're missing the | jq in [...]/api/v1/user | jq .. Without this the -s silences the output altogether (so you don't see anything).

The jq isn't that important. It's actually a really nice JSON filter, for chopping and changing JSON objects on the command line. The command jq . doesn't change the JSON, but jq will still reformat it (including adding colour) so the resulting output is much easier to read.

So, feel free not to pipe the output through jq and copy the raw JSON from frontend, but remember to remove the -s option.

[alrossi]

My CURL incantations aren't working.

[arossi@otfrid scripts]$ curl -E /tmp/x509up_u8773 --capath /etc/grid-security/certificates https://fndcatemp1.fnal.gov:3880/api/v1/user . curl: (35) SSL connect error curl: (6) Couldn't resolve host '.'

[paulmillar]

If you change your additional gid from 1000 to 0 (in gplazma.kpwd), but without changing the gplazma.roles.admin-gid=1000 entry (in dcache.conf), what does the user introspection endpoint return?

[alrossi]

{ "status" : "AUTHENTICATED", "uid" : 8773, "gids" : [ 1530, 1000, 0 ], "username" : "arossi", "email" : [ "arossi@fnal.gov" ], "homeDirectory" : "/", "rootDirectory" : "/pnfs/fs/usr/test/arossi" }

[alrossi]

But still "no roles to assert"

[paulmillar]

If you now change dcache.conf so the line reads

gplazma.roles.admin-gid=0

(keeping the dcache.kpwd file the same), what does the user introspection endpoint return?

[paulmillar]

You probably want session requisite roles, rather than session requires roles in your gplazma.conf file, but that shouldn't be causing this problem.

[alrossi]

There it is:

{ "status" : "AUTHENTICATED", "uid" : 8773, "gids" : [ 1530, 1000, 0 ], "unassertedRoles" : [ "admin" ], "username" : "arossi", "email" : [ "arossi@fnal.gov" ], "homeDirectory" : "/", "rootDirectory" : "/pnfs/fs/usr/test/arossi" }

unasserted role

[alrossi]

That was my first reaction ... it was behaving as if role = 0 were hard coded

[paulmillar]

Which version of dCache is this?

[paulmillar]

Answering my own question: I just learnt via slack this is 4.2.14-SNAPSHOT

[paulmillar]

Possible solution: https://rb.dcache.org/r/11264/