On Sun, Sep 7, 2025 at 10:13 PM Travis Bean via sssd-users
<[email protected]> wrote:

> There are different sssd.conf(5) man pages that describe ownership and
> permissions in different ways.

This is because the wording in the man page was updated when the
ability to run sssd as a non-root user was added.

> In the Arch Linux sssd.conf(5) man page
> (https://man.archlinux.org/man/sssd.conf.5.en) as well as Mankier's
> sssd.conf(5) man page (https://www.mankier.com/5/sssd.conf) it
> mentions, "sssd.conf must be a regular file that is accessible only
> by the user used to run SSSD service or root."

That is the wording as of version 2.11, via commit 8472777 [1]:

    commit 8472777ec472607ea450ddb4c4666017bd0de704
    Author: Alexey Tikhonov <[email protected]>
    Date:   Wed Oct 23 20:59:32 2024 +0200

        INI: relax config files checks

        Only make sure:
         - user is root or sssd
         - group is root or sssd
         - other can't access it

        Don't make any assumptions wrt user/group read/write-ability.

> It is easy to misinterpret this to mean that sssd.conf is accessible
> only by root, which says something about ownership, but is not clear
> on permissions.

If you believe the wording is unclear, suggest better wording.  E.g.:

    The /etc/sssd/sssd.conf file, and all /etc/sssd/conf.d/*.conf
    files, must have an owner of root or the sssd user, a group-owner
    of the root or sssd user, and must be accessible only to the root
    or sssd user.  (Owner root, group sssd, mode 0640 is recommended.)

Better yet, submit a merge request with your preferred wording.

> In the Ubuntu sssd.conf(5) man page
> (https://manpages.ubuntu.com/manpages/noble/man5/sssd.conf.5.html)
> and die.net sssd.conf(5) man page
> (https://linux.die.net/man/5/sssd.conf), it mentions, "sssd.conf
> must be a regular file, owned by root and only root may read from or
> write to the file." This gives a more concise, clearer description
> of ownership and permissions.

That was the wording as of version 2.10, via commit 91d32fe [2]:

    commit 91d32fee16e37e46b7fc43d66f579ba088c45af3
    Author: Alexey Tikhonov <[email protected]>
    Date:   Tue Jul 18 17:10:23 2023 +0200

        SPEC: make ownership of sssd.conf consistent with config folders.

        :packaging: sssd.conf should be owned by user specified
        with '--with-sssd-user=' at build time. If SSSD runs under
        'root' then 'root' ownership of this file will be also
        allowed in runtime.

> Since the ownership and permissions for sssd.conf change to root:sssd
> and 0640, respectively, for version 2.10, it would be a good idea to
> include this in a README file

The man page is the correct location for this information.

Again: if you think the existing wording is unclear, suggest wording
that you think is more clear.

If the sssd project already contributed a README file, then perhaps it
would be reasonable to note in the README file that the
owner/group/mode requirements of the configuration files have changed
in version 2.11.  But it doesn’t, and it doesn’t make sense to add a
README file just to rephrase the information that is already in the
man page.

> unless an example sssd.conf is installed by default to /etc/sssd,
> which would be the most logical choice.

I suspect the reason why many distributions don’t install
/etc/sssd/sssd.conf by default is because /etc/sssd/conf.d/*.conf is
preferred (as is the general trend towards drop-in configuration file
directories), and they believe shipping a default /etc/sssd/sssd.conf
file would cause sysadmins to just edit it (instead of using a drop-in
file in the /etc/sssd/conf.d directory).

[1] https://github.com/SSSD/sssd/commit/8472777ec472607ea450ddb4c4666017bd0de704
[2] https://github.com/SSSD/sssd/commit/91d32fee16e37e46b7fc43d66f579ba088c45af3
-- 
_______________________________________________
sssd-users mailing list -- [email protected]
To unsubscribe send an email to [email protected]
Fedora Code of Conduct: 
https://docs.fedoraproject.org/en-US/project/code-of-conduct/
List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines
List Archives: 
https://lists.fedorahosted.org/archives/list/[email protected]
Do not reply to spam, report it: 
https://pagure.io/fedora-infrastructure/new_issue

Reply via email to