Re: F28 System Wide Change: Make authselect default tool instead of authconfig

[Pavel Březina]

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 


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/smartcard-auth

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.

___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F28 System Wide Change: Make authselect default tool instead of authconfig

[Pavel Březina]

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_under_.2Fsrv.2C_.2Fusr.2Flocal.2C_or_.2Fhome.2F.24USER


Thank you for the info. I created upstream ticket to track this change:
https://github.com/pbrezina/authselect/issues/28
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F28 System Wide Change: Make authselect default tool instead of authconfig

[Zbigniew Jędrzejewski-Szmek]

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_under_.2Fsrv.2C_.2Fusr.2Flocal.2C_or_.2Fhome.2F.24USER

Zbyszek
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F28 System Wide Change: Make authselect default tool instead of authconfig

[Pavel Březina]

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-le...@lists.fedoraproject.org


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F28 System Wide Change: Make authselect default tool instead of authconfig

[nicolas . mailhot]

- 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,

-- 
Nicolas Mailhot
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F28 System Wide Change: Make authselect default tool instead of authconfig

[Tom Hughes]

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-profiles.5.txt.in.in 




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

--
Tom Hughes (t...@compton.nu)
http://compton.nu/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F28 System Wide Change: Make authselect default tool instead of authconfig

[Pavel Březina]

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-profiles.5.txt.in.in



Well /usr/share/authselect/custom is not really the correct location
for local administrator configuration...


What location do you suggest?



Tom


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F28 System Wide Change: Make authselect default tool instead of authconfig

[Pavel Březina]

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.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F28 System Wide Change: Make authselect default tool instead of authconfig

[Jason L Tibbitts III]

> "JF" == John Florian  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<
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F28 System Wide Change: Make authselect default tool instead of authconfig

[Zbigniew Jędrzejewski-Szmek]

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
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F28 System Wide Change: Make authselect default tool instead of authconfig

[Tom Hughes]

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-profiles.5.txt.in.in 


Well /usr/share/authselect/custom is not really the correct location
for local administrator configuration...

Tom

--
Tom Hughes (t...@compton.nu)
http://compton.nu/
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F28 System Wide Change: Make authselect default tool instead of authconfig

[John Florian]

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.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F28 System Wide Change: Make authselect default tool instead of authconfig

[Pavel Březina]

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-profiles.5.txt.in.in


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.


___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F28 System Wide Change: Make authselect default tool instead of authconfig

[John Florian]

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.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org