-
-
Notifications
You must be signed in to change notification settings - Fork 1.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
run systemd unit as authelia user #4982
base: master
Are you sure you want to change the base?
Conversation
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. ArtifactsThese changes once approved by a team member will be published for testing on Buildkite, DockerHub and GitHub Container Registry. Docker Container
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Probably a more descriptive gecos for this user. Also how does this affect users who upgrade? What about users with/without redis?
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. |
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 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. WalkthroughThese 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
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? TipsChatThere are 3 ways to chat with CodeRabbit:
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)
Additionally, you can add CodeRabbit Configration File (
|
Signed-off-by: James Elliott <james-d-elliott@users.noreply.github.com>
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Review Status
Actionable comments generated: 1
Configuration used: CodeRabbit UI
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 theredis
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, settingEnvironment=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.
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
, andauthelia-git
will need two lines added to them, after theinstall ... _pkgname.service
line. The leading source directory needs to be altered slightly from this example to match for theauthelia-bin
andauthelia-git
packages:Similar changes will need to be made for the Debian builds.
The
authelia.sysusers.conf
file creates theauthelia
user (and implicitly the group), and theauthelia.tmpfiles
ensures the configuration directory is owned by this user, so the daemonized process can read the config.The
sysusers.conf
file also adds theauthelia
user to theredis
group.redis
group is implicitly created, and the authelia user is added to it, shouldn't cause any harmredis
group, and "sysusers.conf" will recognize it, and simply ensure theauthelia
user is still a member of that groupmemory
config optionmemory
config option, shouldn't cause any harm also being part of the redis groupredis
config optionredis
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 theredis.md
doc.Summary by CodeRabbit