run systemd unit as authelia user

[feinedsquirrel]

supersedes pull request #3770
because I have since learned how to better manage forks, and make them so I can rebase on upstream, rather than creating new commits that are simply merges of upstream changes.

I'm also removing [WIP], as this has been working for me for the past year, and from my experience admin-ing ubuntu, these changes shouldn't cause any issues there. It is ready for testing across all deploy types.

vv------------ original request ------------vv

Addressing issue #3736

I've tested these changes on my own machine, OS=Arch Linux. The Debian and Docker builds need to be tested.

The PKGBUILDs for authelia, authelia-bin, and authelia-git will need two lines added to them, after the install ... _pkgname.service line. The leading source directory needs to be altered slightly from this example to match for the authelia-bin and authelia-git packages:

<authelia/PKGBUILD>
...
install -Dm644 "${srcdir}/${pkgname}-${pkgver}/${pkgname}.service" "${pkgdir}/usr/lib/systemd/system/${pkgname}.service"
+ install -Dm644 "${srcdir}/${pkgname}-${pkgver}/${pkgname}.sysusers.conf" "${pkgdir}/usr/lib/sysusers.d/${pkgname}.conf"
+ install -Dm644 "${srcdir}/${pkgname}-${pkgver}/${pkgname}.tmpfiles" "${pkgdir}/usr/lib/tmpfiles.d/${pkgname}.conf"
...

Similar changes will need to be made for the Debian builds.

The authelia.sysusers.conf file creates the authelia user (and implicitly the group), and the authelia.tmpfiles ensures the configuration directory is owned by this user, so the daemonized process can read the config.

The sysusers.conf file also adds the authelia user to the redis group.

• case a: the end user doesn't have redis installed
  • The redis group is implicitly created, and the authelia user is added to it, shouldn't cause any harm
  • If the end user installs redis after, that installation will explicitly create the redis group, and "sysusers.conf" will recognize it, and simply ensure the authelia user is still a member of that group
• case b: end user has redis installed, but wants to use memory config option
  • They can still use memory config option, shouldn't cause any harm also being part of the redis group
• case c: the user has redis and wants to use the redis config option
  • The authelia daemon user is already set as a member of the redis group, and all is ready for the end user to use this option.

We shouldn't need to alter any documentation for redis, since the sysusers.conf file handles it. However, if we want to inform the user that the authelia daemon user is made part of that group, I can add a sentence in the redis.md doc.

Summary by CodeRabbit

• Chores
  • Implemented system user configuration for enhanced security and management.
  • Set specific permissions for critical directories to bolster security.
• New Features
  • Introduced environment settings to optimize service performance.

[authelia]

Thanks for choosing to contribute @feinedsquirrel. We lint all PR's with golangci-lint and eslint, I may add a review to your PR with some suggestions.

You are free to apply the changes if you're comfortable, alternatively you are welcome to ask a team member for advice.

Artifacts

These changes once approved by a team member will be published for testing on Buildkite, DockerHub and GitHub Container Registry.

Docker Container

• docker pull authelia/authelia:PR4982
• docker pull ghcr.io/authelia/authelia:PR4982

[james-d-elliott]

Probably a more descriptive gecos for this user. Also how does this affect users who upgrade? What about users with/without redis?

[feinedsquirrel]

Whether the user does or does not have redis installed I believe is answered in the cases (a), (b), and (c) in the top comment. Let me know if they are unclear.
As for upgrade path, I'm thinking I need to alter the tmpfiles.d entry to include (or potentially switch the e line to) a Z line, that will recursively change the mode and ownership.
I also came up with another question. Are we assuming that the installers will always create /etc/authelia/? As a safety mechanism, I'm thinking I will expand the tmpfiles to include a d line to create the directory, retain the e line and add a Z line for updates.
I'll change it tonight when I'm back home, and once I push the update we'll need to test the different scenarios. I'm pretty sure the update path will be solved by adding the Z line.

[coderabbitai]

Warning

Rate Limit Exceeded

@james-d-elliott has exceeded the limit for the number of commits or files that can be reviewed per hour. Please wait 6 minutes and 5 seconds before requesting another review.

How to resolve this issue?

After the wait time has elapsed, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

We recommend that you space out your commits to avoid hitting the rate limit.

How do rate limits work?

CodeRabbit enforces hourly rate limits for each developer per organization.
Our paid plans have higher rate limits than the trial, open-source and free plans. In all cases, we re-allow further reviews after a brief timeout.
Please see our FAQ for further information.

Commits

Files that changed from the base of the PR and between ec1025e and 0cdc8cf.

Walkthrough

These updates focus on enhancing security and operational efficiency for the Authelia service. By specifying a dedicated user and group for running the service, and disabling the health check in certain environments, the changes aim to streamline Authelia's runtime environment. Additionally, the introduction of system user configuration and specific permissions for the Authelia directory further tightens security, ensuring that only authorized processes and users can access critical files and settings.

Changes

Files	Change Summary
authelia.service, authelia@.service	Added User=authelia, Group=authelia, and Environment=AUTHELIA_SERVER_DISABLE_HEALTHCHECK=true in the [Service] section.
authelia.sysusers.conf	Introduced user configuration for creating a system user and associating it with the "redis" group.
authelia.tmpfiles	Set permissions for /etc/authelia to 0700 and ownership to authelia:authelia.

🐇✨
In the land of code and wire,
A rabbit hopped, with changes dire.
"To secure, to streamline," it said with glee,
"For Authelia's sake, let these changes be!"
With a flick and a hop, the deed was done,
A safer service, second to none.
🌟🚀

Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media?

Share

• X
• Mastodon
• Reddit
• LinkedIn

---

Tips

Chat

There are 3 ways to chat with CodeRabbit:

• Review comments: Directly reply to a review comment made by CodeRabbit. Example:
  • I pushed a fix in commit <commit_id>.
  • Generate unit-tests for this file.
  • Open a follow-up GitHub issue for this discussion.
• Files and specific lines of code (under the "Files changed" tab): Tag @coderabbitai in a new review comment at the desired location with your query. Examples:
  • @coderabbitai generate unit tests for this file.
  • @coderabbitai modularize this function.
• PR comments: Tag @coderabbitai in a new PR comment to ask questions about the PR branch. For the best results, please provide a very specific query, as very limited context is provided in this mode. Examples:
  • @coderabbitai generate interesting stats about this repository and render them as a table.
  • @coderabbitai show all the console.log statements in this repository.
  • @coderabbitai read src/utils.ts and generate unit tests.
  • @coderabbitai read the files in the src/scheduler package and generate a class diagram using mermaid and a README in the markdown format.

Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments.

CodeRabbit Commands (invoked as PR comments)

• @coderabbitai pause to pause the reviews on a PR.
• @coderabbitai resume to resume the paused reviews.
• @coderabbitai review to trigger a review. This is useful when automatic reviews are disabled for the repository.
• @coderabbitai resolve resolve all the CodeRabbit review comments.
• @coderabbitai help to get help.

Additionally, you can add @coderabbitai ignore anywhere in the PR description to prevent this PR from being reviewed.

CodeRabbit Configration File (.coderabbit.yaml)

• You can programmatically configure CodeRabbit by adding a .coderabbit.yaml file to the root of your repository.
• The JSON schema for the configuration file is available here.
• If your editor has YAML language server enabled, you can add the path at the top of this file to enable auto-completion and validation: # yaml-language-server: $schema=https://coderabbit.ai/integrations/coderabbit-overrides.v2.json

CodeRabbit Discord Community

Join our Discord Community to get help, request features, and share feedback.

[coderabbitai]

Review Status

Actionable comments generated: 1

Configuration used: CodeRabbit UI

Commits

Files that changed from the base of the PR and between 0299e8d and ec1025e.

Files selected for processing (4)

• authelia.service (1 hunks)
• authelia.sysusers.conf (1 hunks)
• authelia.tmpfiles (1 hunks)
• authelia@.service (1 hunks)

Additional comments: 6

authelia.tmpfiles (1)

• 1-1: The configuration correctly sets the permissions and ownership of the /etc/authelia directory to ensure secure access by the Authelia service. This is a good practice for enhancing security.

authelia.sysusers.conf (1)

• 1-3: The configuration for creating the authelia user and group, and adding the user to the redis group, is correctly implemented. This setup supports various Redis-related deployment scenarios effectively.

authelia@.service (2)

• 7-8: The configuration to run the service as the authelia user and group is correctly implemented, enhancing security by ensuring the service runs with limited permissions.
• 7-8: Setting Environment=AUTHELIA_SERVER_DISABLE_HEALTHCHECK=true may have implications on monitoring and operational visibility. Ensure this configuration aligns with your deployment and monitoring strategies.

authelia.service (2)

• 7-8: The configuration to run the service as the authelia user and group is correctly implemented here as well, enhancing security by ensuring the service runs with limited permissions.
• 7-8: As with the authelia@.service file, setting Environment=AUTHELIA_SERVER_DISABLE_HEALTHCHECK=true may have implications on monitoring and operational visibility. It's important to ensure this configuration aligns with your deployment and monitoring strategies.