= System Wide Change: Make authselect default tool instead of authconfig = https://fedoraproject.org/wiki/Changes/AuthselectAsDefault
Change owner(s): * Pavel Březina <pbrezina AT redhat DOT com>
Replace authconfig with authselect and make authselect a default tool to configure PAM and nsswitch.conf. A compatibility tool will help with transition period from authconfig to authselect. Authselect is a tool to select system authentication and identity sources from a list of supported profiles and it is available to users since Fedora 27. Authselect is designed to be a replacement for authconfig but it takes a different approach to configure the system. Instead of letting the administrator build the pam stack with a tool (which may potentially end up with a broken configuration), it ships several tested stacks (profiles) that solve primary supported use cases and are well tested and supported. At the same time, some obsolete features of authconfig are not supported by authselect. Additionally, authselect is written in C and has a small footprint which allows it to be also part of minimal installations.
== Detailed Description == Authselect allows the administrator to choose one of the supported profiles. A profile provides description of how the resulting pam and nsswitch configuration looks like. The tool is packaged with a default profile set that is fully supported. If an administrator has different needs they can create a custom profile and make it accessible in authselect by dropping it in the tool specific directory.
The authentication and identity configuration is hardcoded within the profile. However each profile is also allowed to contain some conditional modules that can be either enabled or disabled to allow the administrator to enable some optional behaviour such as account locking or ecryptfs support.
Authselect does not configure daemons that provide the selected identity and authentication services such as SSSD or winbind, it only configures PAM and nsswitch. Daemons must be configured manually or through other system tools like realmd or ipa-client-install that are better suited for this task.
The default profile set contains the following profiles: * Local users + SSSD -- local users and remote users are handled by sssd * With optional smartcard or fingerprint authentication * Local users + winbind -- local users are handled by files and remote users by winbind * With optional fingerprint authentication
There is no need for a separate local users profile without SSSD because the SSSD module is not called for local users and it also gracefully detect when the daemon is not running.
Since authselect is very different from the authconfig, we will provide a compatibility tool that will mimic most but not all options of authconfig and translate those operations into an authselect call and configuration changes so we do not break users scripts.
== Scope == * Proposal owners: Authselect is already ready and shipped with Fedora. Owners will provide compatibility tool to help with the transition.
* Other developers: anaconda-core, fprintd-pam, freeipa-client and realmd are packages that depends on authconfig. We will coordinate efforts to either switch those packages to authselect or make sure that the compatibility tool is sufficient to cover their needs.
* Release engineering: #7241: https://pagure.io/releng/issue/7241
* List of deliverables: all
* Policies and guidelines: The policies and guidelines do not need to be updated.
* Trademark approval: N/A (not needed for this Change)
On Fri, 2018-01-05 at 14:50 +0100, Jan Kurik wrote:
The tool is packaged with a default profile set that is fully supported. If an administrator has different needs they can create a custom profile and make it accessible in authselect by dropping it in the tool specific directory.
How? The authselect(8) man page tells me that `authselect show profile_id` will print info about the profile, but I see nothing of any detail. (Perhaps more could be gleaned with `--trace`, but without any apparent dry-run option I'd want a VM to experiment.)
Looking at the package contents doesn't help much either:
$ rpm -ql authselect /usr/bin/authselect /usr/lib/.build-id /usr/lib/.build-id/b6 /usr/lib/.build-id/b6/6bcffc0719e16ebb39e888f8da173aa2bd464e /usr/share/man/man8/authselect.8.gz
So the built-in profiles are hard-coded into the binary? I might have expected a data dir providing these to serve as examples for making new ones.
I also didn't see (nor did I even try searching for) any mention of the upstream project.
Otherwise, this is a very nice write up. I'm mostly curious as our setup uses an openldap directory server for identity and WinAD for authentication. realmd doesn't seem to cover (from a very cursory glance) that arrangement. So I have an eye out for how to best leverage these things, if at all.
On 01/05/2018 03:14 PM, John Florian wrote:
On Fri, 2018-01-05 at 14:50 +0100, Jan Kurik wrote:
The tool is packaged with a default profile set that is fully supported. If an administrator has different needs they can create a custom profile and make it accessible in authselect by dropping it in the tool specific directory.
How? The authselect(8) man page tells me that `authselect show profile_id` will print info about the profile, but I see nothing of any detail. (Perhaps more could be gleaned with `--trace`, but without any apparent dry-run option I'd want a VM to experiment.)
There is also authselect-profiles(5) that explains how profiles works. But it is not yet present in current Fedora packages. I will do new release on Monday.
Looking at the package contents doesn't help much either:
$ rpm -ql authselect /usr/bin/authselect /usr/lib/.build-id /usr/lib/.build-id/b6 /usr/lib/.build-id/b6/6bcffc0719e16ebb39e888f8da173aa2bd464e /usr/share/man/man8/authselect.8.gz
So the built-in profiles are hard-coded into the binary? I might have expected a data dir providing these to serve as examples for making new ones.
Yes, there is a data dir: /usr/share/authselect/ Description of these directories may be seen in the man page, currently at this upstream link: https://github.com/pbrezina/authselect/blob/master/src/man/authselect-profil...
I also didn't see (nor did I even try searching for) any mention of the upstream project.
Otherwise, this is a very nice write up. I'm mostly curious as our setup uses an openldap directory server for identity and WinAD for authentication. realmd doesn't seem to cover (from a very cursory glance) that arrangement. So I have an eye out for how to best leverage these things, if at all.
We had many discussions on this topic while designing and developing authselect. The resolution was to include only sssd and winbind profiles and avoid other use cases and avoid plain ldap and kerberos since they can be implemented with sssd. So the use case that you have mentioned above (different id and auth providers) can be achieved.
We do not want to touch configurations with authselect. But to avoid breaking user scripts, we will configure daemons with the compatibility tool to mimic authconfig behavior wherever possible.
On Fri, 2018-01-05 at 16:02 +0100, Pavel Březina wrote:
On 01/05/2018 03:14 PM, John Florian wrote:
On Fri, 2018-01-05 at 14:50 +0100, Jan Kurik wrote:
The tool is packaged with a default profile set that is fully supported. If an administrator has different needs they can create a custom profile and make it accessible in authselect by dropping it in the tool specific directory.
How? The authselect(8) man page tells me that `authselect show profile_id` will print info about the profile, but I see nothing of any detail. (Perhaps more could be gleaned with `--trace`, but without any apparent dry-run option I'd want a VM to experiment.)
There is also authselect-profiles(5) that explains how profiles works. But it is not yet present in current Fedora packages. I will do new release on Monday.
Ah, that explains a lot. I did fail to mention this was all from the perspective of a F27 system.
Looking at the package contents doesn't help much either:
$ rpm -ql authselect /usr/bin/authselect /usr/lib/.build-id /usr/lib/.build-id/b6 /usr/lib/.build-id/b6/6bcffc0719e16ebb39e888f8da173aa2bd464e /usr/share/man/man8/authselect.8.gz
So the built-in profiles are hard-coded into the binary? I might have expected a data dir providing these to serve as examples for making new ones.
Yes, there is a data dir: /usr/share/authselect/
Doh! I see now that's part of authselect-libs, a package I failed to notice getting installed alongside of authselect itself.
Description of these directories may be seen in the man page, currently at this upstream link: https://github.com/pbrezina/authselect/blob/master/src/man/authselect -profiles.5.txt.in.in
Oh, very nice!
I also didn't see (nor did I even try searching for) any mention of the upstream project.
Otherwise, this is a very nice write up. I'm mostly curious as our setup uses an openldap directory server for identity and WinAD for authentication. realmd doesn't seem to cover (from a very cursory glance) that arrangement. So I have an eye out for how to best leverage these things, if at all.
We had many discussions on this topic while designing and developing authselect. The resolution was to include only sssd and winbind profiles and avoid other use cases and avoid plain ldap and kerberos since they can be implemented with sssd. So the use case that you have mentioned above (different id and auth providers) can be achieved.
That makes sense and seems like a wise choice.
One last thought, how friendly is this going to be with tools like puppet and ansible? For example, would something like this be doable?
exec { 'authselect select sssd': unless => "authselect current | grep -q '^sssd$' && authselect check | grep -q unmodified" }
The idea being to only run to make a change if needed to keep change reports tidy. I can't quite tell at this point because:
$ sudo authselect current No existing configuration detected.
In this sense, it would be helpful if authselect(8) had some details about exit codes. Also, the "check" command could be more explicit about what happens with exit codes/output messages when: * the config was created by authselect and remains unmodified * the config was created by authselect but has since been modified * the config hasn't apparently ever been touched by authselect
Maybe another command like "test" command could be ideal for the job if it did much the same but gave diff output and suitable exit code indicating spot-on vs. needs-change.
I ask because I'd far prefer to have a well maintained tool like authselect managing PAM versus self-hacked file replacements based on old configurations that once may have been correct(ish). PAM syntax is a wee bit too arcane and yet immensely critical to go mucking around haphazardly.
"JF" == John Florian john@doubledog.org writes:
JF> One last thought, how friendly is this going to be with tools like JF> puppet and ansible?
Well it has to be friendlier than authconfig, because generally authconfig isn't and can't be made idempotent. It will randomly reorder things you pass to it on the command line, so most of the time it changes the output when it doesn't need to do so.
It would certainly be nice if authconfig would indicate somehow whether it made changes, and actually change nothing at all unless it needs to do so, but to me it's more important that it provides consistent output.
- J<
On 01/05/2018 04:43 PM, John Florian wrote:
On Fri, 2018-01-05 at 16:02 +0100, Pavel Březina wrote:
On 01/05/2018 03:14 PM, John Florian wrote:
On Fri, 2018-01-05 at 14:50 +0100, Jan Kurik wrote:
The tool is packaged with a default profile set that is fully supported. If an administrator has different needs they can create a custom profile and make it accessible in authselect by dropping it in the tool specific directory.
How? The authselect(8) man page tells me that `authselect show profile_id` will print info about the profile, but I see nothing of any detail. (Perhaps more could be gleaned with `--trace`, but without any apparent dry-run option I'd want a VM to experiment.)
There is also authselect-profiles(5) that explains how profiles works. But it is not yet present in current Fedora packages. I will do new release on Monday.
Ah, that explains a lot. I did fail to mention this was all from the perspective of a F27 system.
Looking at the package contents doesn't help much either:
$ rpm -ql authselect /usr/bin/authselect /usr/lib/.build-id /usr/lib/.build-id/b6 /usr/lib/.build-id/b6/6bcffc0719e16ebb39e888f8da173aa2bd464e /usr/share/man/man8/authselect.8.gz
So the built-in profiles are hard-coded into the binary? I might have expected a data dir providing these to serve as examples for making new ones.
Yes, there is a data dir: /usr/share/authselect/
Doh! I see now that's part of authselect-libs, a package I failed to notice getting installed alongside of authselect itself.
We have put the authselect functionality into a separate library so it is better usable by realmd (that can call it directly instead of executing cli) and other programs that may be interested. We also plan to provide ansible module and probably also python and maybe even dbus bindings. But this is out of scope of F28.
Description of these directories may be seen in the man page, currently at this upstream link: https://github.com/pbrezina/authselect/blob/master/src/man/authselect -profiles.5.txt.in.in
Oh, very nice!
I also didn't see (nor did I even try searching for) any mention of the upstream project.
Otherwise, this is a very nice write up. I'm mostly curious as our setup uses an openldap directory server for identity and WinAD for authentication. realmd doesn't seem to cover (from a very cursory glance) that arrangement. So I have an eye out for how to best leverage these things, if at all.
We had many discussions on this topic while designing and developing authselect. The resolution was to include only sssd and winbind profiles and avoid other use cases and avoid plain ldap and kerberos since they can be implemented with sssd. So the use case that you have mentioned above (different id and auth providers) can be achieved.
That makes sense and seems like a wise choice.
One last thought, how friendly is this going to be with tools like puppet and ansible? For example, would something like this be doable?
It is idempotent so it can be used here as well.
exec { 'authselect select sssd': unless => "authselect current | grep -q '^sssd$' && authselect check | grep -q unmodified" }
The idea being to only run to make a change if needed to keep change reports tidy. I can't quite tell at this point because:
$ sudo authselect current No existing configuration detected.
In this sense, it would be helpful if authselect(8) had some details about exit codes. Also, the "check" command could be more explicit about what happens with exit codes/output messages when:
- the config was created by authselect and remains unmodified
- the config was created by authselect but has since been modified
- the config hasn't apparently ever been touched by authselect
Maybe another command like "test" command could be ideal for the job if it did much the same but gave diff output and suitable exit code indicating spot-on vs. needs-change.
Thank you for your input, we will try to include it soon: https://github.com/pbrezina/authselect/issues/26
I ask because I'd far prefer to have a well maintained tool like authselect managing PAM versus self-hacked file replacements based on old configurations that once may have been correct(ish). PAM syntax is a wee bit too arcane and yet immensely critical to go mucking around haphazardly.
Yes, this is exactly what we aim for.
On 05/01/18 15:02, Pavel Březina wrote:
Yes, there is a data dir: /usr/share/authselect/ Description of these directories may be seen in the man page, currently at this upstream link: https://github.com/pbrezina/authselect/blob/master/src/man/authselect-profil...
Well /usr/share/authselect/custom is not really the correct location for local administrator configuration...
Tom
On 01/05/2018 04:54 PM, Tom Hughes wrote:
On 05/01/18 15:02, Pavel Březina wrote:
Yes, there is a data dir: /usr/share/authselect/ Description of these directories may be seen in the man page, currently at this upstream link: https://github.com/pbrezina/authselect/blob/master/src/man/authselect-profil...
Well /usr/share/authselect/custom is not really the correct location for local administrator configuration...
What location do you suggest?
Tom
On 08/01/18 10:02, Pavel Březina wrote:
On 01/05/2018 04:54 PM, Tom Hughes wrote:
On 05/01/18 15:02, Pavel Březina wrote:
Yes, there is a data dir: /usr/share/authselect/ Description of these directories may be seen in the man page, currently at this upstream link: https://github.com/pbrezina/authselect/blob/master/src/man/authselect-profil...
Well /usr/share/authselect/custom is not really the correct location for local administrator configuration...
What location do you suggest?
Well somewhere in /etc in short.
I mean /usr/share/authselect/custom is fine for local customisation via building your own rpms but not for on the fly changes.
Really nobody should ever be changing anything in /usr (excluding /usr/local) except via package installation/update/removal.
Tom
----- Mail original ----- De: "Tom Hughes"
Well /usr/share/authselect/custom is not really the correct location for local administrator configuration...
What location do you suggest?
Well somewhere in /etc in short.
Like other such packages it needs a hierarchy with default templates in /usr/share and local updates in /etc
Regards,
On Fri, Jan 05, 2018 at 02:50:45PM +0100, Jan Kurik wrote:
= System Wide Change: Make authselect default tool instead of authconfig = https://fedoraproject.org/wiki/Changes/AuthselectAsDefault
Does this change do anything to reduce the number of files in /etc that do not contain local configuration? PAM is currently one of the worst offenders, with /etc/pam.d full of "configuration" files.
Elsewhere in the thread /usr/share/authselect/custom is metioned as directory for admin config. That's OK-ish, as long as you also allow a directory in /etc for the same purpose. /usr must be allowed to be immutable.
Zbyszek
On 01/05/2018 05:21 PM, Zbigniew Jędrzejewski-Szmek wrote:
On Fri, Jan 05, 2018 at 02:50:45PM +0100, Jan Kurik wrote:
= System Wide Change: Make authselect default tool instead of authconfig = https://fedoraproject.org/wiki/Changes/AuthselectAsDefault
Does this change do anything to reduce the number of files in /etc that do not contain local configuration? PAM is currently one of the worst offenders, with /etc/pam.d full of "configuration" files.
No. The files must stay since it would require changes in pam itself and that is out of scope of authselect. Each file corresponds to individual pam service and is read when pam_start(service_name, ...) is called.
Elsewhere in the thread /usr/share/authselect/custom is metioned as directory for admin config. That's OK-ish, as long as you also allow a directory in /etc for the same purpose. /usr must be allowed to be immutable.
Would /usr/local be OK as well?
Zbyszek _______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-leave@lists.fedoraproject.org
On Tue, Jan 09, 2018 at 04:30:56PM +0100, Pavel Březina wrote:
On 01/05/2018 05:21 PM, Zbigniew Jędrzejewski-Szmek wrote:
On Fri, Jan 05, 2018 at 02:50:45PM +0100, Jan Kurik wrote:
= System Wide Change: Make authselect default tool instead of authconfig = https://fedoraproject.org/wiki/Changes/AuthselectAsDefault
Does this change do anything to reduce the number of files in /etc that do not contain local configuration? PAM is currently one of the worst offenders, with /etc/pam.d full of "configuration" files.
No. The files must stay since it would require changes in pam itself and that is out of scope of authselect. Each file corresponds to individual pam service and is read when pam_start(service_name, ...) is called.
Elsewhere in the thread /usr/share/authselect/custom is metioned as directory for admin config. That's OK-ish, as long as you also allow a directory in /etc for the same purpose. /usr must be allowed to be immutable.
Would /usr/local be OK as well?
/usr/local is special. Packages are not allowed to put stuff there [1], and it is instead an alternate install location that is under the control of the administrator. It seems reasonable to support authselect configuration located there.
/usr/share/authselect and /etc/authselect are the two main locations that should be supported, and /usr/local/share/autselect would be an additional option.
[1] https://fedoraproject.org/wiki/Packaging:Guidelines#No_Files_or_Directories_...
Zbyszek
On 01/09/2018 10:36 PM, Zbigniew Jędrzejewski-Szmek wrote:
On Tue, Jan 09, 2018 at 04:30:56PM +0100, Pavel Březina wrote:
On 01/05/2018 05:21 PM, Zbigniew Jędrzejewski-Szmek wrote:
On Fri, Jan 05, 2018 at 02:50:45PM +0100, Jan Kurik wrote:
= System Wide Change: Make authselect default tool instead of authconfig = https://fedoraproject.org/wiki/Changes/AuthselectAsDefault
Does this change do anything to reduce the number of files in /etc that do not contain local configuration? PAM is currently one of the worst offenders, with /etc/pam.d full of "configuration" files.
No. The files must stay since it would require changes in pam itself and that is out of scope of authselect. Each file corresponds to individual pam service and is read when pam_start(service_name, ...) is called.
Elsewhere in the thread /usr/share/authselect/custom is metioned as directory for admin config. That's OK-ish, as long as you also allow a directory in /etc for the same purpose. /usr must be allowed to be immutable.
Would /usr/local be OK as well?
/usr/local is special. Packages are not allowed to put stuff there [1], and it is instead an alternate install location that is under the control of the administrator. It seems reasonable to support authselect configuration located there.
/usr/share/authselect and /etc/authselect are the two main locations that should be supported, and /usr/local/share/autselect would be an additional option.
[1] https://fedoraproject.org/wiki/Packaging:Guidelines#No_Files_or_Directories_...
Thank you for the info. I created upstream ticket to track this change: https://github.com/pbrezina/authselect/issues/28
On 01/05/2018 02:50 PM, Jan Kurik wrote:
= System Wide Change: Make authselect default tool instead of authconfig = https://fedoraproject.org/wiki/Changes/AuthselectAsDefault
Change owner(s):
- Pavel Březina <pbrezina AT redhat DOT com>
Replace authconfig with authselect and make authselect a default tool to configure PAM and nsswitch.conf. A compatibility tool will help with transition period from authconfig to authselect. Authselect is a tool to select system authentication and identity sources from a list of supported profiles and it is available to users since Fedora 27. Authselect is designed to be a replacement for authconfig but it takes a different approach to configure the system. Instead of letting the administrator build the pam stack with a tool (which may potentially end up with a broken configuration), it ships several tested stacks (profiles) that solve primary supported use cases and are well tested and supported. At the same time, some obsolete features of authconfig are not supported by authselect. Additionally, authselect is written in C and has a small footprint which allows it to be also part of minimal installations.
I pushed authselect-0.3 to rawhide. Realmd is converted to authselect and was pushed as well. Anaconda, fprintd will be available soon and ipa changes are still under development, but they all should work now through compatibility tool.
There is a new package: authselect-compat, which provides "authconfig". It is a python script that provides minimum level of compatibility with authconfig. Its purpose it not to reimplement all authconfig features, but it translates it to authselect calls and writes few configuration files in order to allow authentication. But not all authconfig options are supported. It prints a loud deprecation warning. Please, test it.
There is a authselect-migration(7) manual page that will help users with the migration process.
As requested on this list, custom profile directory has been moved to /etc/authselect/custom. Authselect cli has unified and documented return codes so it can be used in users scripts.
I also implemented new template engine, which is not backwards compatible but this is acceptable for this release since it is still in a testing phase. Now the templates are clear and reads very good, see: https://raw.githubusercontent.com/pbrezina/authselect/master/profiles/sssd/s...
There is now authselect-devel package that allows you to use our API in C. We also plan to provide python bindings and ansible module in future versions (F29 scope).
We already have one external contributor, I'm happy to see there is interest in this project from community.
-
Jan Kurik -
Jason L Tibbitts III -
John Florian -
nicolas.mailhot＠laposte.net -
Pavel Březina -
Tom Hughes -
Zbigniew Jędrzejewski-Szmek