Print

Print
Hi Andy,

(Back from vacation today... apologies if you get many rapid-fire emails...)

Indeed, I'm planning on doing this prior to the first release.  Because the macaroons are short-lived and only valid for the local site storage system, it's a bit easier to evolve the claims than in SciTokens (which must be understood by multiple storage systems, all on their own release cycle).

Note that I just pushed libmacaroons to be scheduled for the next EPEL7 and Fedora 28 release.  That means this code's dependencies should be resolvable for those platforms (one of the conditions Andy set out in his original email below).  For me, getting this into the base xrootd install would ease any future pain of coordinating API changes within Xrootd itself -- no need to manage more complex sets of compatible versions, since we only have to target a single version!

Thoughts?

Brian

On Jun 20, 2018, at 3:19 PM, Andrew Hanushevsky <[log in to unmask]> wrote:

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


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