Hi Lukasz,
> I'd like to ask whether following behaviour is desired or it's just a bug:
>
> Given groups.conf file with the following lines related to VO:
>
> "/vo.plgrid.pl"::::
>
> And user proxy like below:
>
> voms-proxy-info --all
> subject : /C=PL/O=GRID/O=Cyfronet/CN=Lukasz Flis - SAM/CN=proxy
> issuer : /C=PL/O=GRID/O=Cyfronet/CN=Lukasz Flis - SAM
> identity : /C=PL/O=GRID/O=Cyfronet/CN=Lukasz Flis - SAM
> type : proxy
> strength : 1024 bits
> path : /home/grid/sam-client/sam-client/plgrid/proxy/proxy
> timeleft : 22:05:00
> === VO vo.plgrid.pl extension information ===
> VO : vo.plgrid.pl
> subject : /C=PL/O=GRID/O=Cyfronet/CN=Lukasz Flis - SAM
> issuer : /C=PL/O=GRID/O=Cyfronet/CN=voms.cyf-kr.edu.pl
> attribute : /vo.plgrid.pl/Role=monitoring/Capability=NULL
> attribute : /vo.plgrid.pl/Role=NULL/Capability=NULL
> timeleft : 22:05:00
> uri : voms.cyf-kr.edu.pl:15004
>
>
>
> WMS is checking mappings just for the first attribute from the proxy and
> the remaining attrs are completely omited.
> In the result I am denied by LCAS/LCMAPS while trying to submit job.
>
> Is this desired? For example CE node behaves in opposite manner so as
> DPM - they are trying to map attributes one by one until success occurs.
This behavior used to be considered desirable: when a user asks for a special
role (e.g. sgm) that for some good or bad reason is not supported by the CE,
the CE should _not_ map the proxy to an ordinary account, causing the job to
fail in the end, possibly after having wasted a lot of time.
Now, these days the tendency is to accept such risks and take advantage of
the benefits that come with wildcards:
"/vo.plgrid.pl/ROLE=lcgadmin":::sgm:
"/vo.plgrid.pl"::::
"/vo.plgrid.pl/*"::::
That last line catches any role or group not explicitly matched earlier.
On the WMS such wildcards do not pose the risks mentioned above, as the WMS
currently does not give different treatments to different users.
|