Default Streams Behavior in LDMS

[nichamon]

A concern has been raised that any authenticated connection can publish Streams to ldmsd. We need the community's input on whether Streams should be enabled or disabled by default.

You can find the note from our meeting on Monday, Dec 2 here. https://github.com/ovis-hpc/ovis-wiki/wiki/2024-12-02#enabledisable-streams

Current Status

• A pull request adding stream_enable and stream_disable commands has been created
• We need to decide on the default behavior whether to enable or disable Streams

How to Participate

To voice your opinion, please add a comment using one of these formats:

For enabling Streams by default:

"enable"

<Your reasoning, explanation, discussion points, concerns, ...>

For disabling Streams by default:

"disable"

<Your reasoning, explanation, discussion points, concerns, ...>

General questions and concerns are also welcome as regular comments.

[nichamon]

Current Behavior (b4.4)

For the original explanation by Narate, see this comment.

Assuming ldmsd running as root:root with authenticated users bob and alice:

• bob can connect to ldmsd and publish anything on any stream (no UID/GID association)
• alice can connect but cannot subscribe (only root can subscribe)

Implications of Default Settings

For the original explanation by Tom, see this comment.

If we change the default to disabled

• Streams data will stop flowing for all existing streams users including at least the following:
  • Sandia, Argonne, LBL
• The configuration command stream_enable would need to be added to their existing configuration scripts in order to allow streams data to be injected into the system

If we leave the default at enabled

• Streams users apps will continue to work as expected without change to their configuration file
• LLNL will have to add the command stream_disable to all of their existing configuration files
• This may be considered inadequate if these configuration files can somehow be changed by a user, but I believe that only @morrone modifies these files
• There is concern that a non-root user can still inject data into the monitoring infrastructure even though a non-root user cannot subscribe to it
  • Note that a non-root user can write a script that uses ldmsd_controller to submit an unlimited number of configuration requests whether or not those requests are honored by the system. If this is a real issue, then we may want to consider rate-control guard rails for non-root users.
  • Note also that configuration requests are not forwarded up the monitoring chain, while streams data is.

Tom proposed adding a configuration.ac option to set the default one way or the other. After some thought I believe this to be a bad idea, because then we would have versions named 4.4.5 that have fundamentally different streams behavior.

[morrone]

FYI, I started a separate discussion topic #1548 to discuss the authorization model on the main branch (v4.5.0 and beyond).