Active Directory Integration test day coming up on Thursday, 2012-10-18

[Jakub Hrozek]

Hi,

The Fedora Test day scheduled for Thursday, October 18th is focused on
Active Directory integration, in particular the realmd project and to some
extent the Active Directory provider of the SSSD.

This test day should be of particular interest to admins who manage Linux
boxes enrolled in an Active Directory domain.

As usual, join us in #fedora-test-day on FreeNode IRC. All the test
instructions are on the wiki:
https://fedoraproject.org/wiki/Test_Day:2012-10-18_Active_Directory

See the full feature page at if you'd like to learn more about the feature:
http://fedoraproject.org/wiki/Features/ActiveDirectory

If you are interested and have the spare cycles, please join us during
this Fedora Test day and help us make sure that Fedora 18 works with Active
Directory out of the box!
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Intent to retire: nss_ldap

[Jakub Hrozek]

Hi,

I would like to retire PADL's nss_ldap and pam_ldap from current Rawhide.

SSSD has been the default in Fedora for quite a few releases with
nss-pam-ldapd as another option for deployments that, for some reason,
do not want to migrate to the SSSD. nss_ldap also seems to be abandoned
upstream.

Are there still any users of nss_ldap? If so, what are the reasons
keeping you from using either nss-pam-ldapd or the SSSD?
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: New Fedora 22 Change proposal: systemd-sysusers

[Jakub Hrozek]

On Wed, Jul 09, 2014 at 10:30:27AM -0400, Miloslav Trmač wrote:
> - Original Message -
> > Hi, for Atomic I'd like to investigate the new systemd-sysusers, so I
> > wrote up a Change:
> > 
> > https://fedoraproject.org/wiki/Changes/SystemdSysusers
> 
> A move to something more declarative makes sense (whether in systemd or 
> through some kind of long-expected declarative rpm facility doesn’t matter to 
> me much.)
> 
> The sysusers tool _really_ needs to use an existing API to manage the user 
> database, though.  As it is, the implementation
> * validates names incorrectly
> * breaks the configurable [UG]ID_MIN logic 
> (http://fedoraproject.org/wiki/Features/1000SystemAccounts, and yes, that is 
> actually used and needed)
> * is likely to break various readers software by not updating the shadow files
> * doesn’t do any auditing.
> We are currently already in a bad position by having two major 
> implementations of maintaining the critical databases, we absolutely don’t 
> want any more.
> 
> At this point this means systemd-sysuers should either run the executables 
> from shadow-utils, or link to libuser.  (Or, I suppose, use accountsservice, 
> but that ends up calling shadow-utils.).
> 
> The plan is to have a single implementation, living around sssd.  (Jakub 
> knows more.)  Either of two API points above are planned to use the sssd 
> implementation, so can be relied on long-term.
> Mirek

The effort Mirek is talking about (a not-too-detailed design page can be
found at [1]) aims at a) using the SSSD database primarily for user
accounts and b) providing a rich DBus API. We actually started with b)
because that's also usable and useful for remote (LDAP, AD, ..) users
which SSSD already handles.

The benefit of using the SSSD database would be the ability of use a
richer set of attributes that the passwd file has. The API would be
usable in a similar fashion accountsservice is now.

Even though SSSD would be in the business of managing local users, I
think the benefits of using SSSD are mostly for managing non-system
accounts. So from this point of view, I don't see what systemd is doing
as conflicting with what we plan on doing.

One issue to keep in mind is that we planned on reverting the order of
the NSS modules to "sss files". Given that systemd-sysusers would write
to the files directly with the libc API, we need to sync the changes
systemd-sysusers to SSSD database, otherwise we risk inconsistencies and
there would also be an extra round-trip to nss_sss before reaching to
nss_files. We /do/ plan on the syncing anyway, because some admins are
still used to vipw their passwd databases and there are legacy scripts
around, but still --  could we, when the SSSD interface is available,
call out from systemd-sysusers to the SSSD, with some fallback for cases
where SSSD is not running?

Are there any plans on changing any of the shadow-utils commands to call
out to systemd-sysusers when adding system users with either useradd
(useradd -r) or libuser?

btw I completely agree that even when we switch to using SSSD to manage
local accounts, the system must still be usable (sans the extra
attributes and the rich API..), if SSSD wasn't able to start for
example.

[1]
https://fedorahosted.org/sssd/wiki/DesignDocs/UsrAccountMgmtConsolidation
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: New Fedora 22 Change proposal: systemd-sysusers

[Jakub Hrozek]

On Thu, Jul 10, 2014 at 12:44:29PM -0400, Simo Sorce wrote:
> On Thu, 2014-07-10 at 17:18 +0200, Jakub Hrozek wrote:
> > We /do/ plan on the syncing anyway, because some admins are
> > still used to vipw their passwd databases and there are legacy scripts
> > around, but still --  could we, when the SSSD interface is available,
> > call out from systemd-sysusers to the SSSD, with some fallback for
> > cases where SSSD is not running?
> 
> Jakub,
> I think we can use inotify on /etc/passwd and friends and reread if
> someone modifies the file.

Yeah, but the "callback" from systemd-sysusers could tell you all the
info right away.

But as I said earlier, we're going to need to re-read and sync anyway
for the vipw case, so it's probably a moot point..

> The important thing is that people don't try to invent new storage
> schemes and additional nsswitch modules and files for the system users.
> 
> Simo.

Right.
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Re: upcoming build and release developer flag day December 12 2016

[Jakub Hrozek]

On Mon, Nov 21, 2016 at 07:46:13AM -0500, Stephen Gallagher wrote:
> On 11/21/2016 04:32 AM, Vít Ondruch wrote:
> > 
> > 
> > Dne 20.11.2016 v 02:11 Dennis Gilmore napsal(a):
> >> koji authentication will be switching to Kerberos. Koji supports multiple 
> >> authentication mechanisms. Fedora infrastructure has set up a freeipa 
> >> instance 
> >> internally that has credential syncing to fas. We are working on ensuring 
> >> that 
> >> gssapi caching is supported so that you can have multiple TGT's and the 
> >> ability to work in multiple reams at once.
> 
> 
> See my other email. I think the issue is that we are missing a krb5.conf.d
> snippet to ensure that the FEDORAPROJECT.ORG TGT is used regardless of 
> whichever
> ticket happens to be the current default.
> 
> > 
> > BTW it would be nice, if it works with SSSD somehow and I don't need to
> > use kinit at all.
> > 
> > 
> 
> That is being worked on. I've asked Jakub Hrozek to come talk about the 
> upcoming
> SSSD KCM work (targeted for F26).
> 

If you acquire the ticket through SSSD (so, log in through PAM with your
Fedora password with SSSD configured with auth_provider=krb5) then SSSD
should already be able to renew tickets for you. I haven't tested this
myself yet, though, but I will.

We're also working on a deamon to manage ccaches as described here:
http://k5wiki.kerberos.org/wiki/Projects/KCM_client
this would allow even ccaches acquired through kinit to be renewed and
hopefully solve some challenged we've seen with KEYRING ccache.

I've posted a design page for review to sssd-devel, I'll post a link
here, too, as soon as the design is reviewed by other SSSD developers.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Heads up: bumping libnl to v3 in rawhide/F17 soon

[Jakub Hrozek]

On Tue, Nov 08, 2011 at 02:13:09PM -0500, Stephen Gallagher wrote:
> On Tue, 2011-11-08 at 12:52 -0600, Dan Williams wrote:
> > It certainly has a different soname, so yeah, we can have a -compat
> > package.  But that would still mean a ton of stuff busted for rebuilds
> > while packages get fixed up.  A few upstream packages already work with
> > libnl2, and the delta between 2 and 3 is hugely smaller than from 1 to
> > 3.
> 
> I don't think rebuilds are as big an issue as broken compatibility. I'd
> recommend carrying compat-libnl1 for at least one Fedora release while
> we port the affected applications to libnl 3.

Hi, Dan,

have you decided on whether there will be a compat library?

Thanks!

-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel

Re: F26 System Wide Change: Kerberos KCM credential cache by default

[Jakub Hrozek]

On Tue, Jan 31, 2017 at 10:57:33AM +0100, Mike Bonnet wrote:
> > == Scope ==
> > * Proposal owners:
> > SSSD developers will implement a KCM server. The krb5-libs package
> > will then switch its default from KEYRING to KCM. The libkrb5 package
> > will require the sssd-kcm subpackage and enable its socket so that the
> > KCM server is socket activated when needed. Please note that the KCM
> > server only listens on a local UNIX socket, not over the network.
> 
> I'm concerned about a low-level library package like krb5-libs depending on
> a higher-level package like sssd-ksm, and possible dependency cycles it
> could create. Also, updating the default config in krb5-libs won't update
> people who have edited their krb5.conf.
> 
> Could the same thing be accomplished by having sssd-ksm drop the required
> config into /etc/krb5.conf.d/, installing sssd-ksm via Workstation comps,
> and skipping the package-level dependencies entirely?

Yes, probably. Honestly, I'm not sure which of the two is preferable to
Fedora.

Shipping a configuration snippet with sssd-kcm that defaults to KCM as
the credential cache type is what I wanted to do for F-25 so that users
who are interested in testing this feature on a stable distribution
could just 'dnf install sssd-kcm'.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F26 System Wide Change: Kerberos KCM credential cache by default

[Jakub Hrozek]

On Tue, Jan 31, 2017 at 09:55:41AM +, Tom Hughes wrote:
> On 31/01/17 09:24, Jan Kurik wrote:
> 
> > With KCM, the Kerberos caches are not stored in a "passive" store, but
> > managed by a daemon. In this setup, the Kerberos library (typically
> > used through an application, like for example, kinit) is a "KCM
> > client" and the daemon is being referred to as a "KCM server". The KCM
> > server will be provided as a socket-activated service of the SSSD
> > deamon.
> 
> Given that kerberos is now required for all packagers, what is the impact of
> this for people that aren't using sssd?
> 
> Is sssd-kcm something that will run and work on it's own without the rest of
> sssd?

Correct, you won't have to configure SSSD[*] or let the users be managed
by SSSD. From a configuration point of view, this change should not even
be visible to the end-user.

krb5-libs would socket-activate the sssd-kcm service which processes the
requests from krb5-libs and might also socket-activate the sssd-secrets
service that manages the persistent store for the ccaches.

In theory, the KCM server could well be a totally separate project
from SSSD (after all, Heimdal has a KCM server as part of their
Kerberos implementation..), but making it a part of SSSD makes it
possible to reuse quite a bit of code that we have for the traditional
SSSD role, where SSSD talks to some remote server for user identity or
authentication. Additionally, the ccaches would be stored in sssd-secrets,
which is already a part of SSSD (but also, as sssd-kcm doesn't depend on
sssd being part of any domain or even serving users to the system
through any of its interfaces..)

[*] there are still some changes pending upstream, but the basic idea is
that SSSD would, if no configuration is provided, generate a 'fallback'
configuration internally.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F26 System Wide Change: Kerberos KCM credential cache by default

[Jakub Hrozek]

On Tue, Jan 31, 2017 at 09:36:59AM +, David Woodhouse wrote:
> On Tue, 2017-01-31 at 10:24 +0100, Jan Kurik wrote:
> > = System Wide Change: Kerberos KCM credential cache by default =
> > https://fedoraproject.org/wiki/Changes/KerberosKCMCache
> > 
> > Change owner(s):
> > * Jakub Hrozek 
> > 
> > 
> > Default to a new Kerberos credential cache type called KCM which is
> > better suited for containerized environments and provides a better
> > user experience in the general case as well.
> > 
> > 
> > == Detailed Description ==
> > Over time, Fedora used different credential cache types to store
> > Kerberos credentials - going from a simple file-based storage (FILE:)
> > to a directory (DIR:) and most recently a kernel-keyring based cache
> > (KEYRING:).
> > 
> > Each of these caches has its own set of advantages and disadvantages.
> > The FILE ccache is very widely supported, but does not allow multiple
> > primary caches in a collection. The DIR cache does, but creating and
> > managing the directories including proper access control can be
> > tricky. The KEYRING cache is not well suited for cases where multiple
> > semi-isolated environments might share the same kernel. Managing
> > credential caches' life cycle is not well solved in neither of these
> > cache types automatically, only with the help of a daemon like SSSD.
> > 
> > The scope of this change is to introduce a new Kerberos credential
> > cache type called KCM and switch to using it by default.
> > 
> > With KCM, the Kerberos caches are not stored in a "passive" store, but
> > managed by a daemon. In this setup, the Kerberos library (typically
> > used through an application, like for example, kinit) is a "KCM
> > client" and the daemon is being referred to as a "KCM server". The KCM
> > server will be provided as a socket-activated service of the SSSD
> > deamon.
> 
> Please ensure this works with winbind. The switch to KEYRING: by
> default didn't — pam_winbind was putting creds in /tmp/krb5cc_$UID
> still, and then they weren't consistently being found there.
> 
> People are still using winbind, because it provides NTLM single-sign-on 
> which is unfortunately still required in most Windows/AD networks.

I'm not really well-versed with winbind, so honestly I'm not sure what
limitation it has wrt Kerberos ccaches. Was this ever reported as a
bug against winbind?

But please see my other reply to the thread, there is nothing inherently
SSSD-specific about this change and nothing that would require you to
use the rest of SSSD.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F26 System Wide Change: Kerberos KCM credential cache by default

[Jakub Hrozek]

On Tue, Jan 31, 2017 at 07:04:33AM -0600, Rex Dieter wrote:
> Jan Kurik wrote:
> 
> > F26 System Wide Change: Kerberos KCM credential cache by default
> 
> Hi, can you please consider changing the name of this change/feature to not 
> use "KCM".  That's an acronym commonly used in kde/plasma for KDE Config 
> Module, e.g.
> https://techbase.kde.org/Development/Tutorials/KCM_HowTo
> to avoid any possible confusion, thanks.

I'm fine with renaming the change but I'm not sure what name would be
better, do you have some suggestion? (I wasn't aware of the collision,
but I suspected the name might not be obvious, that's why I already put
'Kerberos' into the feature name..)

> 
> That said, googling seems to imply that kcm has a history of being commonly 
> used in kerberos contexts too for awhile, so there may be no avoiding it. :(

Correct; note that the KCM acronym is also used in the upstream MIT
Kerberos wiki:
http://k5wiki.kerberos.org/wiki/Projects/KCM_client
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F26 System Wide Change: Kerberos KCM credential cache by default

[Jakub Hrozek]

On Tue, Jan 31, 2017 at 02:36:12PM +0100, Florian Weimer wrote:
> On 01/31/2017 10:36 AM, David Woodhouse wrote:
> > Please ensure this works with winbind. The switch to KEYRING: by
> > default didn't — pam_winbind was putting creds in /tmp/krb5cc_$UID
> > still, and then they weren't consistently being found there.
> 
> OpenJDK could be affected by this as well.

Does OpenJDK work with KERING now or only handles FILE?

Do you have any particular case in mind I could test locally?
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F26 System Wide Change: Kerberos KCM credential cache by default

[Jakub Hrozek]

On Tue, Jan 31, 2017 at 02:49:41PM +0100, Florian Weimer wrote:
> On 01/31/2017 02:38 PM, Jakub Hrozek wrote:
> > On Tue, Jan 31, 2017 at 02:36:12PM +0100, Florian Weimer wrote:
> > > On 01/31/2017 10:36 AM, David Woodhouse wrote:
> > > > Please ensure this works with winbind. The switch to KEYRING: by
> > > > default didn't — pam_winbind was putting creds in /tmp/krb5cc_$UID
> > > > still, and then they weren't consistently being found there.
> > > 
> > > OpenJDK could be affected by this as well.
> > 
> > Does OpenJDK work with KERING now or only handles FILE?
> 
> Hmm.  I assumed it handled KEYRING:, but both jdk8 and jdk9 only seem to
> implement FILE:.  So this change shouldn't result in a regression.

Right, thanks for checking.

The use-case you are describing is also something we would like to
tackle with KCM, although we haven't started implementing this piece yet
at all -- we would like to make it possible, either via a new UNIX
socket exposed by KCM or via some other shim layer to format a FILE:
ccache with a particular principal to some location so that we can use a
modern collection-aware credential cache, but keep using software like
JDK that only handles FILE..
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F26 System Wide Change: Kerberos KCM credential cache by default

[Jakub Hrozek]

On Tue, Jan 31, 2017 at 09:47:05AM -0600, Rex Dieter wrote:
> Jakub Hrozek wrote:
> 
> > On Tue, Jan 31, 2017 at 07:04:33AM -0600, Rex Dieter wrote:
> >> Jan Kurik wrote:
> >> 
> >> > F26 System Wide Change: Kerberos KCM credential cache by default
> >> 
> >> Hi, can you please consider changing the name of this change/feature to
> >> not
> >> use "KCM".  That's an acronym commonly used in kde/plasma for KDE Config
> >> Module, e.g.
> >> https://techbase.kde.org/Development/Tutorials/KCM_HowTo
> >> to avoid any possible confusion, thanks.
> > 
> > I'm fine with renaming the change but I'm not sure what name would be
> > better, do you have some suggestion? 
> 
> just take KCM out?  "Kerberos credential cache by default" should still be 
> fairly clear.  If not (clear), then don't worry about it.

Kerberos credential cache is a fairly generic term. KCM is one type of a
Kerberos credential cache, FILE: is another, KEYRING is another..
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Wild changes in nsswitch.conf

[Jakub Hrozek]

On Mon, May 15, 2017 at 04:35:56PM +0200, Tomas Mraz wrote:
> My current Fedora 26 default nsswitch.conf contains these lines:
> 
> passwd:  sss files systemd
> shadow: files sss
> group:   sss files systemd
> 
> Not sure which package created this configuration, but:
> 
>  * Where is the consistency?
>  * Where is the Fedora Change page that talks about these modifications
> of fairly critical systemwide configuration file?
>  * From which time systemd started to manage user accounts of the
> machine, again where is the Fedora Change page for such change?

Is this what you are looking for?
https://fedoraproject.org/wiki/Changes/SSSDCacheForLocalUsers

That page says:
"""
This change proposes leveraging a new "files" provider SSSD will ship in
the next version in order to resolve also users from the local files.
That way, the "sss" NSS module can be configured before the files module
in nsswitch.conf and the system could leverage sss_nss caching for both
local and remote users. 
"""
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Wild changes in nsswitch.conf

[Jakub Hrozek]

On Mon, May 15, 2017 at 05:22:14PM +0200, Tomas Mraz wrote:
> On Mon, 2017-05-15 at 17:15 +0200, Jakub Hrozek wrote:
> > On Mon, May 15, 2017 at 04:35:56PM +0200, Tomas Mraz wrote:
> > > My current Fedora 26 default nsswitch.conf contains these lines:
> > > 
> > > passwd:  sss files systemd
> > > shadow: files sss
> > > group:   sss files systemd
> > > 
> > > Not sure which package created this configuration, but:
> > > 
> > >  * Where is the consistency?
> > >  * Where is the Fedora Change page that talks about these
> > > modifications
> > > of fairly critical systemwide configuration file?
> > >  * From which time systemd started to manage user accounts of the
> > > machine, again where is the Fedora Change page for such change?
> > 
> > Is this what you are looking for?
> > https://fedoraproject.org/wiki/Changes/SSSDCacheForLocalUsers
> > 
> > That page says:
> > """
> > This change proposes leveraging a new "files" provider SSSD will ship
> > in
> > the next version in order to resolve also users from the local files.
> > That way, the "sss" NSS module can be configured before the files
> > module
> > in nsswitch.conf and the system could leverage sss_nss caching for
> > both
> > local and remote users. 
> > """
> 
> The questions still hold for the consistency between passwd and shadow
> and also for the systemd module present.

Since sssd doesn't handle the password map, being consistent there in
the ordering sense (sss before files) wouldn't make much sense, because
the nss module functions for the shadow map are not even implemented in
nss_sss. We could even omit the sss module from that map altogether.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Wild changes in nsswitch.conf

[Jakub Hrozek]

On Mon, May 15, 2017 at 05:57:50PM +0200, Tomasz Kłoczko wrote:
> On 15 May 2017 at 17:35, Stephen Gallagher  wrote:
> > Tomasz, your tone is needlessly hostile. If you have a question, ask it. If 
> > you want to make a suggestion, make it. But casting aspersions on people 
> > doing work is unacceptable.
> 
> Just please read my question straight. What I've wrote it is very
> simple technical question as glibc NSS code *ALWAYS* is trying to
> communicate with nscd ov. socket before calling any routine from any
> nss_ modules even if nscd is not running.
> In this context implementing in sssd any caching infrastructure is
> more like idiotic than well justified (technically) move.
> Did anyone tested what happens in the system authenticated ov (for
> example) LDAP where ncsd and sssd are running on the same system? 

This has been strongly discouraged for years as Stephen said and sssd
would warn you loudly to syslog if it was running together with nscd and
nscd was caching the maps that sssd handles as well (so, caching hosts
would be fine for example)

> As I
> was in the past few years shadow-utils source code maintainer I know
> that after each modifications files used by NSS (like passwd, shadow,
> group, passwd, group, sgroup, networks and few other in /etc) is
> necessary to communicate with nscd to do do cache clean.
> I would be not surprised if in case enabled caching by sssd and modify
> for example /etc/passwd nothing from shadow-utils will be trying to
> communicate with sssd to clear its passwd map cache.

Right, in this case we try to detect the inconsistency in SSSD and fall
back to nss_files (which is still in nsswitch, just not on the first
place anymore) by just flushing the caches when SSSD detects the files
have changed.

But you are right that in order to be on the safe side, we also need to
invalidate the sssd caches from shadow-utils. And we have a sssd ticket
to track this (admittedly we should have a bugzilla as well, I took a
note to file one)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: Wild changes in nsswitch.conf

[Jakub Hrozek]

On Tue, May 16, 2017 at 08:20:49AM -0400, Stephen Gallagher wrote:
> On 05/16/2017 07:04 AM, Nico Kadel-Garcia wrote:
> > On Mon, May 15, 2017 at 11:37 AM, Stephen Gallagher  
> > wrote:
> >>
> >>
> >> On 05/15/2017 11:30 AM, Jakub Hrozek wrote:
> >>> On Mon, May 15, 2017 at 05:22:14PM +0200, Tomas Mraz wrote:
> > 
> >>>> The questions still hold for the consistency between passwd and shadow
> >>>> and also for the systemd module present.
> >>> Since sssd doesn't handle the password map, being consistent there in
> >>> the ordering sense (sss before files) wouldn't make much sense, because
> >>> the nss module functions for the shadow map are not even implemented in
> >>> nss_sss. We could even omit the sss module from that map altogether.
> >>
> >> The only historical reason it is there is because authconfig didn't
> >> differentiate them; it made all changes to shadow identically to passwd.
> >> I don't know if that's still the case, but I'm pretty sure it was when
> >> we first added SSSD support to authconfig. It's not harmful, since the
> >> SSSD client just immediately returns with an appropriate NSS error code
> >> if it's asked for any shadow map function.
> > 
> > Stephen, activating *any* service you don't need and using it for work
> > that cannot possibly succeed is potentially harmful to performance and
> > stability of the system. It may not be notably destructive or very
> > expensive, and in this case would normally be harmless. But it helps
> > create another possible point of failure in a system critical
> > function. The underlying problem there would seem to be one of
> > authconfig activating features pointlessly in /etc/nsswitch.cnf, not
> > of the sssd software itself.
> > 
> 
> To clarify, having this in nsswitch.conf does *NOT* activate the SSSD service 
> on
> the system (in and of itself). And the system around it is carefully designed 
> so
> that if SSSD is not running or accessible, it immediately returns control to
> glibc which then goes through the classic nss_files path.
> 
> > Tomasz's tone has been consistently rude. In this cae, he did seem to
> > have a point. sssd is, in this case, re-inventing some of the wheels
> > of nscd. He could have said so much more nicely. 
> 
> Yes, SSSD does reinvent nscd, because nscd did not meet the needs of a great
> many people. Its caching methodology is too simplistic (it uses the exact same
> approach to deal with all possible name-service maps, which means that its
> decision process has to be least-common-denominator). We very much set out to
> replace nscd because it didn't work well and the upstream at the time was
> immovable on many of these points. While this may no longer be true, that ship
> has sailed.
> 
> 
> And Tomasz? sssd was
> > apparently *designed* with philosophy much like that of systemd. It's
> > supposed to be a unified set of tools replacing a lot of already
> > existing functionality, and adding some useful features.
> > Unfortunately, its unifying multiple service and multiple host
> > authentication doesn't seem to have become popular: Most folks I've
> > seen using Kerberos and LDAP, which sssd was designed to integrate,
> > have simply ignored sssd and gone straight to the more multi-platform
> > supported Samba.
> 
> Just a reminder: anecdotes do not equal rigorous data :)
> 
> SSSD is in extremely wide use around the world and is the preferred
> LDAP/Kerberos client option in all of the major Linux distributions.
> 
> 
>  And authconfig has never really evolved to provide
> > more robust, consistent activation of localized configurations,
> > settings which are overwritten without notification when authconfig is
> > run. Authconfig is a fairly dangerous tool if you need to customize
> > local configurations, including its inability to remove obsolete
> > domains or to support multiple domains in the /etc/krb5.cnf
> > configurations, and its consistent overwriting of localized
> > configurations for password expiration in /etc/nsswitch.cnf.
> > 
> 
> Yes, authconfig is *not* a good tool for managing centralized authentication
> services and its upstream has been unable to keep up with the changing needs 
> of
> the system. That's why work is under way to replace it with more robust 
> tools. I
> think Jakub can talk more about that.

Yeah, there is a project in a fairly early stage (so, we don't even have
a Fedora Change page yet, but we need to file one for F-27) to replace
authconfig.

The basic idea is that instead of trying to generate a nss/pam stack
based on what the admin called authconfig with (and hope for the best)
the tool would include a curated and well tested set of stacks to support
the common configuration types.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F27 System Wide Change: Kerberos KCM credential cache by default

[Jakub Hrozek]

On Tue, Jun 20, 2017 at 09:25:49AM +0200, Pavel Cahyna wrote:
> Hi,
> 
> On Tue, Jun 20, 2017 at 07:42:27AM +0200, Jan Kurik wrote:
> > = System Wide Change: Kerberos KCM credential cache by default =
> > https://fedoraproject.org/wiki/Changes/KerberosKCMCache
> 
> "The design is described in more detail on the SSSD wiki."
> 
> It is not, the link redirects to a page about fedorahosted.org
> retirement.

Sorry, your are right, I fixed the link (this feature was submitted
during f-26 timeframe when fh.o was still up and I forgot to change the
links when I re-submitted the feature..)

The correct link is:
https://docs.pagure.org/SSSD.sssd/design_pages/kcm.html

> 
> > Change owner(s):
> > * Jakub Hrozek 
> > 
> > Default to a new Kerberos credential cache type called KCM which is
> > better suited for containerized environments and provides a better
> > user experience in the general case as well.
> 
> I wonder what is the relation to the daemon of the same name ansd
> similar purpose distributed with Heimdal
> http://h5l.org/manual/HEAD/info/heimdal/Credential-cache-server-_002d-KCM.html.
> Will they be compatible? 

Yes, more or less. The wire protocol is the same and I used MIT client
libraries with Heimdal server bit during development. Not all server
commands are implemented, only the subset that MIT client implements.

There are some features supported by Heimdal but not supported yet by SSSD's
KCM, like renewals, but those will be added. There are some features we
chose to explicitly not add (or not enable by default), like listing all
ccaches known to KCM server by root.

Hopefully the sssd upstream design page would help..

> Will code be shared?

No, the Heimdal deamon relies on internal Heimdal API quite a bit. We
also want to support multiple 'storage back ends' for the ccaches, while
Heimdal only stores the ccaches in memory.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F27 System Wide Change: Kerberos KCM credential cache by default

[Jakub Hrozek]

On Tue, Jun 20, 2017 at 08:55:49AM -0400, Daniel Walsh wrote:
> On 06/20/2017 04:21 AM, Jakub Hrozek wrote:
> > On Tue, Jun 20, 2017 at 09:25:49AM +0200, Pavel Cahyna wrote:
> > > Hi,
> > > 
> > > On Tue, Jun 20, 2017 at 07:42:27AM +0200, Jan Kurik wrote:
> > > > = System Wide Change: Kerberos KCM credential cache by default =
> > > > https://fedoraproject.org/wiki/Changes/KerberosKCMCache
> > > "The design is described in more detail on the SSSD wiki."
> > > 
> > > It is not, the link redirects to a page about fedorahosted.org
> > > retirement.
> > Sorry, your are right, I fixed the link (this feature was submitted
> > during f-26 timeframe when fh.o was still up and I forgot to change the
> > links when I re-submitted the feature..)
> > 
> > The correct link is:
> >  https://docs.pagure.org/SSSD.sssd/design_pages/kcm.html
> > 
> > > > Change owner(s):
> > > > * Jakub Hrozek 
> > > > 
> > > > Default to a new Kerberos credential cache type called KCM which is
> > > > better suited for containerized environments and provides a better
> > > > user experience in the general case as well.
> > > I wonder what is the relation to the daemon of the same name ansd
> > > similar purpose distributed with Heimdal
> > > http://h5l.org/manual/HEAD/info/heimdal/Credential-cache-server-_002d-KCM.html.
> > > Will they be compatible?
> > Yes, more or less. The wire protocol is the same and I used MIT client
> > libraries with Heimdal server bit during development. Not all server
> > commands are implemented, only the subset that MIT client implements.
> > 
> > There are some features supported by Heimdal but not supported yet by SSSD's
> > KCM, like renewals, but those will be added. There are some features we
> > chose to explicitly not add (or not enable by default), like listing all
> > ccaches known to KCM server by root.
> > 
> > Hopefully the sssd upstream design page would help..
> > 
> > > Will code be shared?
> > No, the Heimdal deamon relies on internal Heimdal API quite a bit. We
> > also want to support multiple 'storage back ends' for the ccaches, while
> > Heimdal only stores the ccaches in memory.
> > ___
> > devel mailing list -- devel@lists.fedoraproject.org
> > To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> 
> How will I access this feature inside of a container? 

Bind-mount the KCM server socket into the container.

> If there is a leaked
> socket into the container, what kind of access control is built into your
> server to prevent root inside of one container effecting/accessing the
> credentials of different containers?

Well, UID of the peer accessing the socket is the access control key right
now. Unlike Heimdal's KCM, root doesn't have any special powers (with
Heimdal's KCM, root can list any ccache, with our implementation, only
that of UID 0).

Do you have a different suggestion?
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F27 System Wide Change: Kerberos KCM credential cache by default

[Jakub Hrozek]

On Tue, Jun 20, 2017 at 04:23:30PM -0400, Daniel Walsh wrote:
> On 06/20/2017 02:45 PM, Jakub Hrozek wrote:
> > On Tue, Jun 20, 2017 at 08:55:49AM -0400, Daniel Walsh wrote:
> > > On 06/20/2017 04:21 AM, Jakub Hrozek wrote:
> > > > On Tue, Jun 20, 2017 at 09:25:49AM +0200, Pavel Cahyna wrote:
> > > > > Hi,
> > > > > 
> > > > > On Tue, Jun 20, 2017 at 07:42:27AM +0200, Jan Kurik wrote:
> > > > > > = System Wide Change: Kerberos KCM credential cache by default =
> > > > > > https://fedoraproject.org/wiki/Changes/KerberosKCMCache
> > > > > "The design is described in more detail on the SSSD wiki."
> > > > > 
> > > > > It is not, the link redirects to a page about fedorahosted.org
> > > > > retirement.
> > > > Sorry, your are right, I fixed the link (this feature was submitted
> > > > during f-26 timeframe when fh.o was still up and I forgot to change the
> > > > links when I re-submitted the feature..)
> > > > 
> > > > The correct link is:
> > > >   https://docs.pagure.org/SSSD.sssd/design_pages/kcm.html
> > > > 
> > > > > > Change owner(s):
> > > > > > * Jakub Hrozek 
> > > > > > 
> > > > > > Default to a new Kerberos credential cache type called KCM which is
> > > > > > better suited for containerized environments and provides a better
> > > > > > user experience in the general case as well.
> > > > > I wonder what is the relation to the daemon of the same name ansd
> > > > > similar purpose distributed with Heimdal
> > > > > http://h5l.org/manual/HEAD/info/heimdal/Credential-cache-server-_002d-KCM.html.
> > > > > Will they be compatible?
> > > > Yes, more or less. The wire protocol is the same and I used MIT client
> > > > libraries with Heimdal server bit during development. Not all server
> > > > commands are implemented, only the subset that MIT client implements.
> > > > 
> > > > There are some features supported by Heimdal but not supported yet by 
> > > > SSSD's
> > > > KCM, like renewals, but those will be added. There are some features we
> > > > chose to explicitly not add (or not enable by default), like listing all
> > > > ccaches known to KCM server by root.
> > > > 
> > > > Hopefully the sssd upstream design page would help..
> > > > 
> > > > > Will code be shared?
> > > > No, the Heimdal deamon relies on internal Heimdal API quite a bit. We
> > > > also want to support multiple 'storage back ends' for the ccaches, while
> > > > Heimdal only stores the ccaches in memory.
> > > > ___
> > > > devel mailing list -- devel@lists.fedoraproject.org
> > > > To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> > > How will I access this feature inside of a container?
> > Bind-mount the KCM server socket into the container.
> > 
> > > If there is a leaked
> > > socket into the container, what kind of access control is built into your
> > > server to prevent root inside of one container effecting/accessing the
> > > credentials of different containers?
> > Well, UID of the peer accessing the socket is the access control key right
> > now. Unlike Heimdal's KCM, root doesn't have any special powers (with
> > Heimdal's KCM, root can list any ccache, with our implementation, only
> > that of UID 0).
> > 
> > Do you have a different suggestion?
> > ___
> > devel mailing list -- devel@lists.fedoraproject.org
> > To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> 
> I would want an SELinux check added to it, to allow us to keep the caches
> separate, based on SELinux.  This would mean you would need to have an
> SELinux label associated with each cache.
> 
> I would also be careful about capabilities.
> 
> The bottom line with this is if I have two different containers creating
> keyrings, how does you cache differentiate the the keyrings from each other.
> If I am in container1 and I do a kinit, and it container2, I can use the
> keyring, that is a HUGE security violation.

Well, isn't the kernel KEYRING: cache (which we default to..) working
exactly this way at the moment?

With the KCM deamon, you at least selectively mount the KCM socket into
the containers where you /want/ to share the ccache based on the peer
UID.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: F27 System Wide Change: Kerberos KCM credential cache by default

[Jakub Hrozek]

On Wed, Jun 21, 2017 at 08:23:10AM +0200, Jakub Hrozek wrote:
> On Tue, Jun 20, 2017 at 04:23:30PM -0400, Daniel Walsh wrote:
> > On 06/20/2017 02:45 PM, Jakub Hrozek wrote:
> > > On Tue, Jun 20, 2017 at 08:55:49AM -0400, Daniel Walsh wrote:
> > > > On 06/20/2017 04:21 AM, Jakub Hrozek wrote:
> > > > > On Tue, Jun 20, 2017 at 09:25:49AM +0200, Pavel Cahyna wrote:
> > > > > > Hi,
> > > > > > 
> > > > > > On Tue, Jun 20, 2017 at 07:42:27AM +0200, Jan Kurik wrote:
> > > > > > > = System Wide Change: Kerberos KCM credential cache by default =
> > > > > > > https://fedoraproject.org/wiki/Changes/KerberosKCMCache
> > > > > > "The design is described in more detail on the SSSD wiki."
> > > > > > 
> > > > > > It is not, the link redirects to a page about fedorahosted.org
> > > > > > retirement.
> > > > > Sorry, your are right, I fixed the link (this feature was submitted
> > > > > during f-26 timeframe when fh.o was still up and I forgot to change 
> > > > > the
> > > > > links when I re-submitted the feature..)
> > > > > 
> > > > > The correct link is:
> > > > >   https://docs.pagure.org/SSSD.sssd/design_pages/kcm.html
> > > > > 
> > > > > > > Change owner(s):
> > > > > > > * Jakub Hrozek 
> > > > > > > 
> > > > > > > Default to a new Kerberos credential cache type called KCM which 
> > > > > > > is
> > > > > > > better suited for containerized environments and provides a better
> > > > > > > user experience in the general case as well.
> > > > > > I wonder what is the relation to the daemon of the same name ansd
> > > > > > similar purpose distributed with Heimdal
> > > > > > http://h5l.org/manual/HEAD/info/heimdal/Credential-cache-server-_002d-KCM.html.
> > > > > > Will they be compatible?
> > > > > Yes, more or less. The wire protocol is the same and I used MIT client
> > > > > libraries with Heimdal server bit during development. Not all server
> > > > > commands are implemented, only the subset that MIT client implements.
> > > > > 
> > > > > There are some features supported by Heimdal but not supported yet by 
> > > > > SSSD's
> > > > > KCM, like renewals, but those will be added. There are some features 
> > > > > we
> > > > > chose to explicitly not add (or not enable by default), like listing 
> > > > > all
> > > > > ccaches known to KCM server by root.
> > > > > 
> > > > > Hopefully the sssd upstream design page would help..
> > > > > 
> > > > > > Will code be shared?
> > > > > No, the Heimdal deamon relies on internal Heimdal API quite a bit. We
> > > > > also want to support multiple 'storage back ends' for the ccaches, 
> > > > > while
> > > > > Heimdal only stores the ccaches in memory.
> > > > > ___
> > > > > devel mailing list -- devel@lists.fedoraproject.org
> > > > > To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> > > > How will I access this feature inside of a container?
> > > Bind-mount the KCM server socket into the container.
> > > 
> > > > If there is a leaked
> > > > socket into the container, what kind of access control is built into 
> > > > your
> > > > server to prevent root inside of one container effecting/accessing the
> > > > credentials of different containers?
> > > Well, UID of the peer accessing the socket is the access control key right
> > > now. Unlike Heimdal's KCM, root doesn't have any special powers (with
> > > Heimdal's KCM, root can list any ccache, with our implementation, only
> > > that of UID 0).
> > > 
> > > Do you have a different suggestion?
> > > ___
> > > devel mailing list -- devel@lists.fedoraproject.org
> > > To unsubscribe send an email to devel-le...@lists.fedoraproject.org
> > 
> > I would want an SELinux check added to it, to allow us to keep the caches
> > separate, based on SELinux.  This would mean you would need to have an
> > SELinux label associated with each cache.

btw I filed https://pagure.io/SSSD/sssd/issue/3434 to track this

> > 
> > I would also be careful about capabilities.
> > 
> > The bottom line with this is if I have two different containers creating
> > keyrings, how does you cache differentiate the the keyrings from each other.
> > If I am in container1 and I do a kinit, and it container2, I can use the
> > keyring, that is a HUGE security violation.
> 
> Well, isn't the kernel KEYRING: cache (which we default to..) working
> exactly this way at the moment?
> 
> With the KCM deamon, you at least selectively mount the KCM socket into
> the containers where you /want/ to share the ccache based on the peer
> UID.
> ___
> 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: F27 System Wide Change: Kerberos KCM credential cache by default

[Jakub Hrozek]

On Wed, Jun 21, 2017 at 09:01:04AM +0200, Pavel Cahyna wrote:
> On Tue, Jun 20, 2017 at 08:45:48PM +0200, Jakub Hrozek wrote:
> > Well, UID of the peer accessing the socket is the access control key right
> > now. Unlike Heimdal's KCM, root doesn't have any special powers (with
> > Heimdal's KCM, root can list any ccache, with our implementation, only
> > that of UID 0).
> 
> How will rpc.gssd retrieve users' tickets then?

Maybe I misspoke -- root can be configured to list any user's ccache,
e.g:
KRB5CCNAME=KCM:123 klist
although I wanted to disable this by default. I admit I didn't think
about NFS. Does rpc.gssd still need to access any user's ccache even in
the age of gssproxy?
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: What does 141 mean?

[Jakub Hrozek]

> On 20 Sep 2018, at 06:47, Alexander Bokovoy  wrote:
> 
> On ke, 19 syys 2018, Björn Persson wrote:
>> Alexander Bokovoy wrote:
>>> Can you provide output from
>>> 
>>> export KRB5_TRACE=/dev/stderr
>>> klist -A
>>> kinit
>>> fedpkg build
>>> 
>>> ?
>> 
>> The log is attached. I tried it twice as Tony Nelson suggested. The
>> first attempt failed as usual, but the second attempt was successful.
>> 
>> Björn Persson
> 
>> [beorn@tag gnat-srpm-macros]$ export KRB5_TRACE=/dev/stderr
>> [beorn@tag gnat-srpm-macros]$ klist -A
>> Ticket cache: KCM:1000
>> Default principal: rombobe...@fedoraproject.org
>> 
>> Valid starting   Expires  Service principal
>> 2018-09-17 05:24:43  2018-09-18 05:24:35  
>> krbtgt/fedoraproject@fedoraproject.org
>>  renew until 2018-09-24 05:24:35
>> 2018-09-17 05:27:25  2018-09-18 05:24:35  
>> HTTP/koji.fedoraproject@fedoraproject.org
>>  renew until 2018-09-24 05:24:35
>> [beorn@tag gnat-srpm-macros]$ kinit rombobe...@fedoraproject.org
>> [14092] 1537389788.507256: Getting initial credentials for 
>> rombobe...@fedoraproject.org
>> [14092] 1537389788.507258: Sending request (207 bytes) to FEDORAPROJECT.ORG
>> [14092] 1537389788.507259: Resolving hostname id.fedoraproject.org
>> [14092] 1537389788.507260: TLS certificate name matched 
>> "id.fedoraproject.org"
>> [14092] 1537389789.71948: Sending HTTPS request to https 152.19.134.142:443
>> [14092] 1537389789.71949: Received answer (322 bytes) from https 
>> 152.19.134.142:443
>> [14092] 1537389789.71950: Terminating TCP connection to https 
>> 152.19.134.142:443
>> [14092] 1537389794.417687: Response was not from master KDC
>> [14092] 1537389794.417688: Received error from KDC: -1765328359/Additional 
>> pre-authentication required
>> [14092] 1537389794.417691: Processing preauth types: 16, 15, 14, 136, 19, 
>> 147, 2, 133
>> [14092] 1537389794.417692: Selected etype info: etype aes256-cts, salt 
>> "3'Ds5@-0:LIC'DI@", params ""
>> [14092] 1537389794.417693: Received cookie: MIT
>> Password for rombobe...@fedoraproject.org:
>> [14092] 1537389816.394788: AS key obtained for encrypted timestamp: 
>> aes256-cts/3ECA
>> [14092] 1537389816.394790: Encrypted timestamp (for 1537389811.329323): 
>> plain 301AA011180F3230313830393139323034315AA105020305066B, encrypted 
>> 9D4E22D8C8E839FD08FDEF5513D8B3ECA58449937FAA393FC840524E9FBB4C5AAD7AAF5747A5F9B36B608199BB2A62A85BAED55317B1BA18
>> [14092] 1537389816.394791: Preauth module encrypted_timestamp (2) (real) 
>> returned: 0/Success
>> [14092] 1537389816.394792: Produced preauth for next request: 133, 2
>> [14092] 1537389816.394793: Sending request (302 bytes) to FEDORAPROJECT.ORG
>> [14092] 1537389816.394794: Resolving hostname id.fedoraproject.org
>> [14092] 1537389816.394795: TLS certificate name matched 
>> "id.fedoraproject.org"
>> [14092] 1537389817.98943: Sending HTTPS request to https 140.211.169.196:443
>> [14092] 1537389817.98944: Received answer (795 bytes) from https 
>> 140.211.169.196:443
>> [14092] 1537389817.98945: Terminating TCP connection to https 
>> 140.211.169.196:443
>> [14092] 1537389822.391083: Response was not from master KDC
>> [14092] 1537389822.391084: Processing preauth types: 19
>> [14092] 1537389822.391085: Selected etype info: etype aes256-cts, salt 
>> "3'Ds5@-0:LIC'DI@", params ""
>> [14092] 1537389822.391086: Produced preauth for next request: (empty)
>> [14092] 1537389822.391087: AS key determined by preauth: aes256-cts/3ECA
>> [14092] 1537389822.391088: Decrypted AS reply; session key is: 
>> aes256-cts/A5E2
>> [14092] 1537389822.391089: FAST negotiation: available
>> [14092] 1537389822.391090: Initializing KCM:1000 with default princ 
>> rombobe...@fedoraproject.org
>> [beorn@tag gnat-srpm-macros]$ echo $?
>> 141
> So there is something wrong happening right after starting to save the cred 
> into KCM credentials
> cache.
> 
> Jakub (in CC:), do you see any reason for this?

Not without logs. Please file a bug so that we can take a look.

It would be nice to:
 - edit /etc/sssd/sssd.conf
 - add:
   [kcm]
   debug_level = 10
 - systemctl restart sssd # to regenerate the configuration
 - systemctl restart sssd-kcm # restart the KCM deamon
- attach the logs at /var/log/sssd/*

> 
>> [beorn@tag gnat-srpm-macros]$ fedpkg build
>> [14333] 1537389921.736427: ccselect module realm chose cache KCM:1000 with 
>> client principal rombobe...@fedoraproject.org for server principal 
>> HTTP/koji.fedoraproject@fedoraproject.org
>> [14333] 1537389921.736428: Getting credentials rombobe...@fedoraproject.org 
>> -> HTTP/koji.fedoraproject@fedoraproject.org using ccache KCM:1000
>> [14333] 1537389921.736429: Retrieving rombobe...@fedoraproject.org -> 
>> HTTP/koji.fedoraproject@fedoraproject.org from KCM:1000 with result: 
>> -1765328243/Matching credential not found
>> [14333] 1537389921.736430: Retrieving rombobe...@fedoraproject.org -> 
>> krbtgt/fedoraproject@fedoraproject.org from KCM:1000 with result: 
>> 0/Success

Re: F27 Self Contained Change: Authselect: new tool to replace authconfig

[Jakub Hrozek]

On Tue, Jul 18, 2017 at 08:30:57PM +0100, Tom Hughes wrote:
> On 18/07/17 15:26, Stephen Gallagher wrote:
> 
> > On Tue, Jul 18, 2017 at 10:17 AM Tom Hughes  > > wrote:
> > 
> > Well none of my newly upgraded F26 machines appear to be running it ;-)
> > 
> > I said "default". So for fresh installs this is the case.
> 
> Yes my laptop, which had been installed with F26, was indeed running it.
> 
> It appears that whatever enabled it (anaconda?) did so by manually editing

The default nsswitch.conf is owned by libc, which, if I remember the
discussions with Florian earlier is also not deemed ideal.

> nsswitch.conf however, so running "authconfig --updateall" to rebuild the
> configuration would have disabled it.

I would say this is a bug in authconfig (and by the way, this is one of
the reasons curated and tested NSS/PAM stacks would be more reliable than
generating the stack based on user input where more or less anything goes..)
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Re: systemd 238 and sysusers

[Jakub Hrozek]

> On 7 Mar 2018, at 15:53, Stephen Gallagher  wrote:
> 
> 
> 
> On Wed, Mar 7, 2018 at 9:50 AM Simo Sorce  wrote:
> On Wed, 2018-03-07 at 14:24 +, Zbigniew Jędrzejewski-Szmek wrote:
> > On Wed, Mar 07, 2018 at 02:00:03PM +0100, Florian Weimer wrote:
> > > On 03/07/2018 01:55 PM, Stephen Gallagher wrote:
> > > > Yes, SSSD monitors those files and automatically cleans its cache.
> > > >
> > > > However, you're right. On systems not using SSSD (which I suspect is a
> > > > nontrivial number of systems running systemd...), people are probably 
> > > > still
> > > > using nss and we should call `nscd -i passwd` (plus `group` and `shadow`
> > > > where appropriate) if the nscd service is running.
> > >
> > > nscd is supposed to monitor these files, too.
> > >
> > > But is this monitoring sufficient?  RPM will immediately start
> > > installing files after the scriptlet has finished.  nscd and SSSD
> > > may not have completed their cache invalidation at this point, so
> > > this looks like a race condition to me.
> >
> > That sounds like a bug in the cache implementation. nscd and sssd
> > simply _must_ ensure that their copy of passwd is the latest one.
> > Shouldn't be a problem to call fstatat() before generating an answer
> > an invalidate the cache if it returns a different mtime then previously.
> 
> The fast cache we provide from sssd is read directly by the client
> (sssd nsswitch plugin) without the involvement of the sssd daemon (or
> it would be slow).
> so there are windows for races if you change a passwd file and then
> immediately read out of the fast caches.
> This is not something we can fix without severely compromising
> performance, which is the raison d'etre of those caches.
> 
> 
> Probably the simplest solution for sysusers would be to execute the change 
> and then run a wait-loop calling `getpwnam()` until it gets 
> a successful result (or some reasonable timeout expires, indicating a bug 
> elsewhere). That way, it can be trusted that sysusers won't return until the 
> user addition is truly valid.

btw if nss_sss wouldn’t find the user, then, assuming the default order on 
Fedora, the request would just fall back to nss_files. So I don’t think the 
race condition when /adding/ a user is something to worry about. But the other 
way around, if the user was removed, there can be a small race between removing 
the user and nss_sss having its cache flushed. I don’t think this is any 
different from nscd either.
___
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org