 |
 |
Hi Andreas, dCache currently embeds the UID / GID(s) of the original entity that generated the token into the token itself. XRootD does not really have a concept of "file ownership" (authorization module is completely separated from the filesystem module), so I don't currently include this in the XRootD-generated macaroon. As I've been trying out a few use cases locally (locally, XRootD sits on top of HDFS which, like EOS, does have file ownership), I'm hitting ownership issues like you outline below. I think the XRootD-generated token is going to include the user and group info too for the case where XRootD is sitting on top of distributed filesystems. Brian > On Jun 20, 2018, at 7:33 AM, Andreas-Joachim Peters <[log in to unmask]> wrote: > > I have one question if you use macaroons for writing. If I allow with a macaroon to write into 'my' directory, will a file be created with my identity or the identity of the authenticated client with the macaroon? Or is the identity for creatoin also specified in the macaroon? Reading is clear. > > Cheers Andreas. > > > On Wed, Jun 20, 2018 at 1:58 PM, Fabrizio Furano <[log in to unmask] <mailto:[log in to unmask]>> wrote: > Hi, > > On 20.06.18 12:56, Paul Millar wrote: > > Hi Fabrizio, > > > > On 20/06/18 11:48, Fabrizio Furano wrote: > >> Paul, surely it's available in DPM 1.10 (latest in epel) > > > > Excellent. > > > > Could you say which option needs tweaking in order to enable the support? > > > > The DPM v1.10 release notes don't seem to mention macaroons much. > > indeed, we don't consider them a released feature ready for > prime time. Eventually they will. > > To enable then, one needs to make sure that the Apache config > contains: > - (in the Location match for /dpm) NSMacaroonSecret <secret> > - SSLVerifyClient must be "optional" > > Cheers > Fabrizio > > > > > >> It may be available on slightly older DPMs if the sysadmin has > >> upgraded the HTTP frontend alone (lcgdm-dav 0.20). Needless to say, > >> I don't encourage package alchemies in prod setups. > > > > :-D > > > >> About the authentication, I take the statement "every authenticated > >> client", > >> which in our world may mean X509, X509/VOMS > > > > Yes, it includes X.509. For dCache, this is also true for > > OpenID-Connect, Kerberos, username+password and macaroons. > > > > (You can even use a macaroon when requesting a fresh macaroon.) > > > > I'm working on adding SciToken support now. > > > >> That was for generating. I am a bit puzzled about authorization. Really > >> you don't apply any kind of authorization to generate a macaroon? Do you > >> check everything only when a macaroon is received? > > > > Yes, beyond a global enable/disable switch. > > > > The CPU cost of generating a macaroon is rather trivial. > > > > In the Birgisson et al paper, they measured the crypo overhead of > > minting a macaroon (in Python) at 20 µs, plus 55 µs per caveat. For > > comparison they measured RSA keygen (as used by SciToken) as taking 54 > > ms (54000 µs) in OpenSSL. So a typical macaroon is about two orders of > > magnitude faster to generate than an RSA key-pair. > > > > There's no problem with multiple requests filling up any storage: > > typically macaroons share the same secret. > > > > It doesn't authorise users to do anything they can't already do, > > especially with X.509 proxies. > > > > For example, consider a user that generates and emails a friend a > > macaroon that grants the bearer the ability to read some data. > > > > That user could email their friend an X.509 proxy. > > > > Failing that, they could even download the data and simply email it to > > their friend. > > > > At least with macaroons, the user can limit activity to reading data (no > > deletion) and only a specific portion of the namespace. > > > >> For the records, the DPM implementation is considered experimental > >> because it may miss something... however it's good to gain experience. > > > > Agreed. > > > > Cheers, > > > > Paul. > > > > ######################################################################## > Use REPLY-ALL to reply to list > > To unsubscribe from the XROOTD-DEV list, click the following link: > https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=XROOTD-DEV&A=1 <https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=XROOTD-DEV&A=1> > > > Use REPLY-ALL to reply to list > > To unsubscribe from the XROOTD-DEV list, click the following link: > https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=XROOTD-DEV&A=1 <https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=XROOTD-DEV&A=1> ######################################################################## Use REPLY-ALL to reply to list To unsubscribe from the XROOTD-DEV list, click the following link: https://listserv.slac.stanford.edu/cgi-bin/wa?SUBED1=XROOTD-DEV&A=1