Help w/documentation on access control

[baallan]

Is there a feature in v4 that allows an aggregator (L2) to connect to another (L1) in "read-only" mode, and if so how do I specify that? Or is this post-v4?

The use case is: L2 is in another administrative domain and should

• be able to get data from the L1
• not be able to send control signals changing any configuration in L1 or L0.
• not be able to (successfully) make a DOS attack on L1's aggregation ability.

Per-data-set restrictions are not important in this use case. If the feature exists, please point me at the right man page or source code.

I'm imagining this would be a feature (read-only) somehow defined when a listening port argument is passed to ldmsd at startup.

[valleydlr]

There is currently no permissions functionality associated with a listening port. Permissions are defined on a metric set if using the "munge" authentication method.

---

From: Benjamin Allan [email protected] Sent: Wednesday, February 5, 2020 10:35 AM To: ovis-hpc/ovis Cc: Subscribed Subject: [EXTERNAL] [ovis-hpc/ovis] Help w/documentation on access control (#139)

Is there a feature in v4 that allows an aggregator (L2) to connect to another (L1) in "read-only" mode, and if so how do I specify that? Or is this post-v4?

The use case is: L2 is in another administrative domain and should

• be able to get data from the L1
• not be able to send control signals changing any configuration in L1 or L0.
• not be able to (successfully) make a DOS attack on L1's aggregation ability.

Per-data-set restrictions are not important in this use case. If the feature exists, please point me at the right man page or source code.

I'm imagining this would be a feature (read-only) somehow defined when a listening port argument is passed to ldmsd at startup.

You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHubhttps://github.com/ovis-hpc/ovis/issues/139?email_source=notifications&email_token=AAOKRWMQX2VIN3743FUPHZLRBL2H5A5CNFSM4KQPF2SKYY3PNVWWK3TUL52HS4DFUVEXG43VMWVGG33NNVSW45C7NFSM4ILI52WA, or unsubscribehttps://github.com/notifications/unsubscribe-auth/AAOKRWLIPLOGL22KOC7JLU3RBL2H5ANCNFSM4KQPF2SA.

[baallan]

@tom95858 can you comment on the feasibility of supporting the use case above in the next major version or as a patch on v4?

I would imagine defining a listening port with optional properties "read only" and (at admin discretion) "no auth required". Alternately, could we make a port behave such that if the munge user is not the daemon owner the port goes into read-only mode? This would allow applications to get at root-owned daemon metric sets without authenticating.

[tom95858]

All configuration requests are access controlled. Only a connection from the same owner/group as the running daemon can change the configuration. Status requests, however, are allowed for other. As @valleydlr mentioned access to metric sets are also controlled.

Presently, only the munge auth method provides reliable uid/gid information. ovis and none are always 0/0 and therefore are all or nothing.

[baallan]

So will the ogc munge extension work in progress in some way enable the scenario where L2 and its local munge is not in on the secret of the munge on the L1 server?

[tom95858]

The multi-domain munge support will allow the aggregator to associate some endpoints with one domain and others with a second domain. But even absent that support, if a user other than the euid/egid of the running ldmsd daemon cannot modify the running configuration. The munge support simply allows the daemon to reliably know the remote euid/egid.