 |
 |
Hi Brian, I've created a repo for you: https://github.com/xrootd/xrootd-macaroons How do we proceed with versioning of external components? Do we keep it in line with core xrootd packages? Cheers, Michal ________________________________________ From: Hanushevsky, Andrew B. [[log in to unmask]] Sent: 20 June 2018 22:19 To: [log in to unmask] Cc: Andreas Joachim Peters; Fabrizio Furano; Paul Millar; Fabrizio Furano; xrootd-dev; Simon, Michal; Oliver Keeble Subject: Re: Macaroons support for XrdHttp Actually, it would be good if the macaroon contained UID/GID (or whatever you consider describing ownership) from the get go -- even if it is not used for certain system. These things evolve quickly and I don't think it would be good to constrain the evolution simply because we don't have enough information. Putting this in after the fact is usually far more problematic than one initially assumes. Andy On Wed, 20 Jun 2018, Brian Bockelman wrote: > 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