DAOS-16129 packaging: fix daos_metrics permissions

[Michael-Hennecke]

make /usr/bin/daos_metrics g+s daos_server, to allow unprivileged users to call it

Before requesting gatekeeper:

• [ ] Two review approvals and any prior change requests have been resolved.
• [ ] Testing is complete and all tests passed or there is a reason documented in the PR why it should be force landed and forced-landing tag is set.
• [ ] Features: (or Test-tag*) commit pragma was used or there is a reason documented that there are no appropriate tags for this PR.
• [ ] Commit messages follows the guidelines outlined here.
• [ ] Any tests skipped by the ticket being addressed have been run and passed in the PR.

Gatekeeper:

• [ ] You are the appropriate gatekeeper to be landing the patch.
• [ ] The PR has 2 reviews by people familiar with the code, including appropriate owners.
• [ ] Githooks were used. If not, request that user install them and check copyright dates.
• [ ] Checkpatch issues are resolved. Pay particular attention to ones that will show up on future PRs.
• [ ] All builds have passed. Check non-required builds for any new compiler warnings.
• [ ] Sufficient testing is done. Check feature pragmas and test tags and that tests skipped for the ticket are run and now pass with the changes.
• [ ] If applicable, the PR has addressed any potential version compatibility issues.
• [ ] Check the target branch. If it is master branch, should the PR go to a feature branch? If it is a release branch, does it have merge approval in the JIRA ticket.
• [ ] Extra checks if forced landing is requested
  • [ ] Review comments are sufficiently resolved, particularly by prior reviewers that requested changes.
  • [ ] No new NLT or valgrind warnings. Check the classic view.
  • [ ] Quick-build or Quick-functional is not used.
• [ ] Fix the commit message upon landing. Check the standard here. Edit it to create a single commit. If necessary, ask submitter for a new summary.

[github-actions[bot]]

Ticket title is 'daos_metrics command does not work for unprivileged users' Status is 'In Progress' Labels: 'lrz' https://daosio.atlassian.net/browse/DAOS-16129

[daosbuild1]

Test stage Build RPM on EL 9 completed with status UNSTABLE. https://build.hpdd.intel.com//job/daos-stack/job/daos/view/change-requests/job/PR-14664/2/execution/node/355/log

[daosbuild1]

Test stage Build RPM on EL 8 completed with status UNSTABLE. https://build.hpdd.intel.com//job/daos-stack/job/daos/view/change-requests/job/PR-14664/2/execution/node/296/log

[daosbuild1]

Test stage Build RPM on Leap 15.5 completed with status UNSTABLE. https://build.hpdd.intel.com//job/daos-stack/job/daos/view/change-requests/job/PR-14664/2/execution/node/358/log

[daosbuild1]

Test stage Build DEB on Ubuntu 20.04 completed with status UNSTABLE. https://build.hpdd.intel.com//job/daos-stack/job/daos/view/change-requests/job/PR-14664/2/execution/node/293/log

[daosbuild1]

Test stage NLT on EL 8.8 completed with status UNSTABLE. https://build.hpdd.intel.com/job/daos-stack/job/daos//view/change-requests/job/PR-14664/2/testReport/

[Michael-Hennecke]

I don't necessarily have a problem with this change, but I am curious about the motivation behind it. What is the use case where an admin would want to run daos_metrics on a server, but does not have root access to the machine?

a nonprivileged icinga user is calling the daos_metrics command on the servers as part of their monitoring framework. and there really is no reason why this should require superuser privileges.

[daosbuild1]

Test stage Build RPM on EL 9 completed with status UNSTABLE. https://build.hpdd.intel.com//job/daos-stack/job/daos/view/change-requests/job/PR-14664/3/execution/node/338/log

[daosbuild1]

Test stage Build RPM on EL 8 completed with status UNSTABLE. https://build.hpdd.intel.com//job/daos-stack/job/daos/view/change-requests/job/PR-14664/3/execution/node/365/log

[daosbuild1]

Test stage Build RPM on Leap 15.5 completed with status UNSTABLE. https://build.hpdd.intel.com//job/daos-stack/job/daos/view/change-requests/job/PR-14664/3/execution/node/282/log

[daosbuild1]

Test stage Build DEB on Ubuntu 20.04 completed with status UNSTABLE. https://build.hpdd.intel.com//job/daos-stack/job/daos/view/change-requests/job/PR-14664/3/execution/node/387/log

[mjmac]

I don't necessarily have a problem with this change, but I am curious about the motivation behind it. What is the use case where an admin would want to run daos_metrics on a server, but does not have root access to the machine?

a nonprivileged icinga user is calling the daos_metrics command on the servers as part of their monitoring framework. and there really is no reason why this should require superuser privileges.

... Sure. Seems strange to use daos_metrics (a developer tool) instead of Prometheus (the defacto standard for metrics export and storage), but variety makes the world go 'round, I guess. I will point out that daos_metrics was not designed for use in production, and while I'm not aware of any specific problems with it, I wouldn't feel comfortable saying that it's a tested and supported solution.

[daltonbohning]

... Sure. Seems strange to use daos_metrics (a developer tool) instead of Prometheus (the defacto standard for metrics export and storage), but variety makes the world go 'round, I guess. I will point out that daos_metrics was not designed for use in production, and while I'm not aware of any specific problems with it, I wouldn't feel comfortable saying that it's a tested and supported solution.

At least for testing purposes I find daos_metrics CSV format super useful.

[daltonbohning]

RPM build is failing with https://build.hpdd.intel.com/blue/organizations/jenkins/daos-stack%2Fdaos/detail/PR-14664/3/pipeline/190/

[2024-06-28T18:44:35.870Z] daos-server.x86_64: E: setgid-binary /usr/bin/daos_metrics daos_server 2755

[2024-06-28T18:44:35.870Z] daos-server.x86_64: E: non-standard-executable-perm /usr/bin/daos_metrics 2755

[mjmac]

At least for testing purposes I find daos_metrics CSV format super useful.

And that's one of the envisioned use cases for the tool. I'm just expressing surprise (and maybe a little dismay) that apparently someone is building a production monitoring solution around daos_metrics. I'd like to understand the motivation for doing that instead of using an agent that can read Prometheus-format metrics.

[phender]

Looks like we have the daos_metrics file listed twice with a duplicate entry causing https://github.com/daos-stack/daos/pull/14664#issuecomment-2200802270

[daosbuild1]

Test stage Build RPM on EL 9 completed with status UNSTABLE. https://build.hpdd.intel.com//job/daos-stack/job/daos/view/change-requests/job/PR-14664/4/execution/node/367/log

[daosbuild1]

Test stage Build RPM on EL 8 completed with status UNSTABLE. https://build.hpdd.intel.com//job/daos-stack/job/daos/view/change-requests/job/PR-14664/4/execution/node/344/log

[daosbuild1]

Test stage Build RPM on Leap 15.5 completed with status UNSTABLE. https://build.hpdd.intel.com//job/daos-stack/job/daos/view/change-requests/job/PR-14664/4/execution/node/373/log

[daosbuild1]

Test stage Build DEB on Ubuntu 20.04 completed with status UNSTABLE. https://build.hpdd.intel.com//job/daos-stack/job/daos/view/change-requests/job/PR-14664/4/execution/node/351/log

[daosbuild1]

Test stage Build RPM on EL 9 completed with status UNSTABLE. https://build.hpdd.intel.com//job/daos-stack/job/daos/view/change-requests/job/PR-14664/5/execution/node/318/log

[daosbuild1]

Test stage Build RPM on EL 8 completed with status UNSTABLE. https://build.hpdd.intel.com//job/daos-stack/job/daos/view/change-requests/job/PR-14664/5/execution/node/305/log

[daosbuild1]

Test stage Build RPM on Leap 15.5 completed with status UNSTABLE. https://build.hpdd.intel.com//job/daos-stack/job/daos/view/change-requests/job/PR-14664/5/execution/node/302/log

[daosbuild1]

Test stage Build RPM on EL 9 completed with status UNSTABLE. https://build.hpdd.intel.com//job/daos-stack/job/daos/view/change-requests/job/PR-14664/6/execution/node/366/log

[daosbuild1]

Test stage Build RPM on EL 8 completed with status UNSTABLE. https://build.hpdd.intel.com//job/daos-stack/job/daos/view/change-requests/job/PR-14664/6/execution/node/349/log

[daosbuild1]

Test stage Build RPM on Leap 15.5 completed with status UNSTABLE. https://build.hpdd.intel.com//job/daos-stack/job/daos/view/change-requests/job/PR-14664/6/execution/node/355/log

[daosbuild1]

Test stage Build DEB on Ubuntu 20.04 completed with status UNSTABLE. https://build.hpdd.intel.com//job/daos-stack/job/daos/view/change-requests/job/PR-14664/6/execution/node/341/log

[brianjmurrell]

I will point out that daos_metrics was not designed for use in production, and while I'm not aware of any specific problems with it, I wouldn't feel comfortable saying that it's a tested and supported solution.

Given these concerns and given that we are setgid()ing this process, has it been audited for safety in doing so?

There is a reason that rpmlint raises warnings about setgid binaries. Such binaries should be very thoroughly audited for code safety and least privilege, dropping the elevated permissions as soon their need has been satisfied.

The ideal suid/setgid binary does everything it needs elevated permissions for immediately upfront and then drops the elevated permissions before it does anything else (like processing the data, etc.) in order to minimize the amount of code running with privileges. It doesn't sound like this is what this binary is doing and that we are just elevating privilege on a binary that was never designed to run in this manner.

Are there alternatives to setgid()ing this binary? Can the user/account that needs to run this binary with privileges just have the group added to their supplemental groups list by the site-admin on sites where this is necessary?