On Fri, Jul 21, 2017 at 05:12:20PM +0200, Jacquelin Charbonnel wrote:
At now, I enroll diskless Fedora26 workstations (with stateless Linux) into
my IPA domain.
Inside the readonly root image, /etc/sysconfig/selinux points :
and /etc/sssd/sssd.conf points :
selinux_provider = none
So, authentication of a domain account seems well working, but nevertheless
at each time, journalctl says :
juil. 21 16:11:32 pc-f26.math systemd-coredump:
Process 22017 (selinux_child) of user 0 dumped core.
Stack trace of thread 22017:
#0 0x00007f60bac8dd24 semanage_seuser_key_free (libsemanage.so.1)
#1 0x00005639b0b5326d set_seuser (selinux_child)
#2 0x00005639b0b52a3f main (selinux_child)
#3 0x00007f60ba8b94da __libc_start_main (libc.so.6)
#4 0x00005639b0b52dba _start (selinux_child)
Can you file a bug against sssd and add the core there? This shouldn't
(Also, adding logs would be nice to find out why is selinux child being
called despite selinux_provider=none)
> Hope this helps...
> Le 14/10/2016 à 10:02, Jakub Hrozek a écrit :
> > On Fri, Oct 14, 2016 at 09:44:11AM +0200, Sumit Bose wrote:
> > > On Fri, Oct 14, 2016 at 12:41:23AM +0200, Jacquelin Charbonnel wrote:
> > > > Thank you for this information. Yes, /tmp is writable.
> > > >
> > > > My problem is : access are sometimes definitively refused for random
> > > > who wants to log in diskless workstations.
> > > > But if this banned user tries to connect to the single machine which
> > > > the fs in rw mode, it's work, and this solve immediately its
problem on all
> > > > the other stateless machines !? Strange...
> > >
> > > Maybe it is the selinux_provider, iirc at least in older version it used
> > > to write some data somewhere below /etc/selinux/. You can easily test
> > > this by setting 'selinux_provider = none' in the domain section in
> > > ssd.conf.
> > Aah, that's probably it. We no longer write to the directory directly,
> > but we call libsemanage functions that do.
> Jacquelin Charbonnel - (+33)2 4173 5397
> CNRS Mathrice/LAREMA - Campus universitaire d'Angers