DAOS-18324 common: create files as 0660 instead of 0600

[janekmi]

Allow users who are part of the daos_server group to access created files. It would allow run dlck/ddb as a normal user instead of as root which is a bad a practice and sometimes is impossible.

• drop the mode argument when open() is called without O_CREAT. In this case mode is ignored and providing a value is nothing but confusing.

Steps for the author:

• Commit message follows the guidelines.
• Appropriate Features or Test-tag pragmas were used.
• Appropriate Functional Test Stages were run.
• At least two positive code reviews including at least one code owner from each category referenced in the PR.
• Testing is complete. If necessary, forced-landing label added and a reason added in a comment.

After all prior steps are complete:

• Gatekeeper requested (daos-gatekeeper added as a reviewer).

[github-actions]

Ticket title is 'DLCK & DDB could use setuid/setgid to be easily runnable by any user in the system'
Status is 'Awaiting Verification'
https://daosio.atlassian.net/browse/DAOS-18324

[daosbuild3]

Test stage NLT on EL 8.8 completed with status UNSTABLE. https://jenkins-3.daos.hpc.amslabs.hpecorp.net/job/daos-stack/job/daos//view/change-requests/job/PR-17330/1/testReport/

[daosbuild3]

Test stage Functional Hardware Medium MD on SSD completed with status FAILURE. https://jenkins-3.daos.hpc.amslabs.hpecorp.net//job/daos-stack/job/daos/view/change-requests/job/PR-17330/1/execution/node/1323/log

[NiuYawei]

Hmm, shouldn't the DLCK being executed by root or the same user who runs DAOS server?

[janekmi]

Till now both DDB and DLCK could be run only by the root user which was pointed out as not a good practice. Hence encouraged by @Michael-Hennecke we started to look into other possibilities. All the details are in the ticket and in the comments there but to answer to your questions briefly:

• The daos_server user is intentionally a nologin user.
• Requiring to run both DDB and DLCK as root does not sound as a good practice nor it is practical.
• Allowing users from the daos_server group to run DDB/DLCK has at least three benefits:
  • Administrator has the full control over who has and who has not access to these tools.
  • You do not have to be an administrator to use them. You just have to request access.
  • Administrator can give you access without compromising the whole system. Belonging to the group does not give you more power than absolutely necessary.

[Nasf-Fan]

Allow users who are part of the daos_server group to access created files. It would allow run dlck/ddb as a normal user instead of as root which is a bad a practice and sometimes is impossible.

My main concern is that ddb can be used to dump the whole vos tree (and the value). If we do not restrict the permission properly, then there maybe risk of non-authoritative data access.

[daosbuild3]

Test stage Functional Hardware Medium Verbs Provider MD on SSD completed with status FAILURE. https://jenkins-3.daos.hpc.amslabs.hpecorp.net//job/daos-stack/job/daos/view/change-requests/job/PR-17330/1/execution/node/1313/log

[janekmi]

@Nasf-Fan wrote:

My main concern is that ddb can be used to dump the whole vos tree (and the value). If we do not restrict the permission properly, then there maybe risk of non-authoritative data access.

I completely agree we have to keep this in mind. At the same time, when the only option to run DDB/DLCK is to have the complete control over the system (root), we give the administrator no flexibility. They have to give up the whole control over the system if they want to let in anyone else to use these tools. Which is a security risk in of itself.

No matter whether access stays at it is right now (root-only) or for the members of the daos_server group, administrator still has full control over who will get the access. Either to root password / sudo (very risky) or being added to the daos_server group (restrictive).

[janekmi]

@NiuYawei @Nasf-Fan I guess the key question is what use cases for DLCK/DDB we predict:

1. Whether the one who will use these tools ought to be also in complete control of the system hence requiring root privilege is sufficient, or
2. we think it may not always be the case hence requesting the root privilege is cumbersome or maybe even compromising the security of the rest of the system.

If we think 2. is the case than I think controlling access to these tools via the daos_server group is the cleanest solution.