https://bugzilla.redhat.com/show_bug.cgi?id=1857104
Bug ID: 1857104
Summary: Using FreeIPA breaks IPv4/IPv6 flags for SSH
Product: Fedora
Version: 32
Status: NEW
Component: sssd
Assignee: sssd-maintainers(a)lists.fedoraproject.org
Reporter: ossman(a)cendio.se
QA Contact: extras-qa(a)fedoraproject.org
CC: abokovoy(a)redhat.com, atikhono(a)redhat.com,
jhrozek(a)redhat.com, lslebodn(a)redhat.com,
mzidek(a)redhat.com, pbrezina(a)redhat.com,
rharwood(a)redhat.com, sbose(a)redhat.com,
ssorce(a)redhat.com,
sssd-maintainers(a)lists.fedoraproject.org
Target Milestone: ---
Classification: Fedora
Description of problem:
If a client is configured using ipa-client-install then the -4 and -6 flags
stop working for ssh.
Version-Release number of selected component (if applicable):
Doesn't matter. Seen on RHEL 6 through 8, and on current Fedora.
How reproducible:
100%
Steps to Reproduce:
1. ipa-client-install
2. ssh -4 host.example.com
Actual results:
Connected via IPv6
Expected results:
Connected via IPv4
Additional info:
The bug is that sss_ssh_knownhostsproxy is configured on the client and that
command doesn't respect the flags given to ssh.
The issue affects all hosts, not just those part of the same FreeIPA domain.
A practical effect of this is that connections get rejected or misbehave
because of IP based rules in place for this connection.
--
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=1853261
Bug ID: 1853261
Summary: sssd fails to start on read-only filesystem
Product: Fedora
Version: rawhide
Status: NEW
Component: sssd
Assignee: sssd-maintainers(a)lists.fedoraproject.org
Reporter: zbyszek(a)in.waw.pl
QA Contact: extras-qa(a)fedoraproject.org
CC: abokovoy(a)redhat.com, atikhono(a)redhat.com,
jhrozek(a)redhat.com, lslebodn(a)redhat.com,
mzidek(a)redhat.com, pbrezina(a)redhat.com,
rharwood(a)redhat.com, sbose(a)redhat.com,
ssorce(a)redhat.com,
sssd-maintainers(a)lists.fedoraproject.org
Target Milestone: ---
Classification: Fedora
Description of problem:
sssd refuses to start when /var/log is read-only. It is obviously a problem
when trying to recover
from a file system issue. Since logging is non-essential, sssd should just
continue. At most is
should emit a warning.
$ touch /var/tmp/foo
touch: cannot touch '/var/tmp/foo': Read-only file system
$ sudo systemctl start sssd.service
Job for sssd.service failed because the control process exited with error code.
See "systemctl status sssd.service" and "journalctl -xe" for details.
[fedora@workstation-uefi ~]$
Broadcast message from systemd-journald@workstation-uefi (Thu 2020-07-02
11:16:46 CEST):
sssd[900]: Could not open file [/var/log/sssd/sssd.log]. Error: [30][Read-only
file system]
Broadcast message from systemd-journald@workstation-uefi (Thu 2020-07-02
11:16:47 CEST):
sssd[903]: Could not open file [/var/log/sssd/sssd.log]. Error: [30][Read-only
file system]
Broadcast message from systemd-journald@workstation-uefi (Thu 2020-07-02
11:16:47 CEST):
sssd[905]: Could not open file [/var/log/sssd/sssd.log]. Error: [30][Read-only
file system]
Broadcast message from systemd-journald@workstation-uefi (Thu 2020-07-02
11:16:47 CEST):
sssd[906]: Could not open file [/var/log/sssd/sssd.log]. Error: [30][Read-only
file system]
Broadcast message from systemd-journald@workstation-uefi (Thu 2020-07-02
11:16:47 CEST):
sssd[907]: Could not open file [/var/log/sssd/sssd.log]. Error: [30][Read-only
file system]
We see multiple issues here:
- the main one is that sssd should not fail to start as described above
- but also, why is sssd not just logging to the journal? Why is it spamming
with broadcast messages?
If sssd would just log to the journal like any modern service, all those
problems
would be avoided.
Version-Release number of selected component (if applicable):
sssd-2.3.0-2.fc33.x86_64
How reproducible:
Deterministic
Steps to Reproduce:
1. Make /var/log read-only, either by not remounting the filesystems rw, or by
using udev.blockdev-read-only with systemd-246+
2. Try to start sssd
--
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=1850548
Bug ID: 1850548
Summary: sssd not renewing/obtaining krb ticket at login
Product: Fedora
Version: 32
Status: NEW
Component: sssd
Assignee: sssd-maintainers(a)lists.fedoraproject.org
Reporter: gwync(a)protonmail.com
QA Contact: extras-qa(a)fedoraproject.org
CC: abokovoy(a)redhat.com, atikhono(a)redhat.com,
jhrozek(a)redhat.com, lslebodn(a)redhat.com,
mzidek(a)redhat.com, pbrezina(a)redhat.com,
rharwood(a)redhat.com, sbose(a)redhat.com,
ssorce(a)redhat.com,
sssd-maintainers(a)lists.fedoraproject.org
Target Milestone: ---
Classification: Fedora
Prior to f32, my sssd/krb5 setup allowed login and ensured a current krb5
ticket at login. With f32 it allows login but doesn't obtain or renew a ticket.
Manual kinit works fine after login. The only error I see in the logs at the
moment at login time is:
[dp_target_run_constructor] (0x0010): Target [resolver] constructor failed
[95]: Operation not supported
--
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=1669607
Pavel Březina <pbrezina(a)redhat.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Assignee|sssd-maintainers(a)lists.fedo |jstephen(a)redhat.com
|raproject.org |
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=1648521
--- Comment #30 from Pavel Březina <pbrezina(a)redhat.com> ---
Hi everyone. I'm sorry for the delay. We have changed the autofs responder in
sssd-2.2.3 quite a lot (available since F31 from March this year) that should
improve the situation. We are also working with autofs maintainer to improve
the communication between autofs and sssd further so this no longer happens.
In the mean time, you can try setting sss_master_map_wait in autofs.conf to
some non-zero value. Please, let me know if this helps and if there are further
issues.
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=1854469
Bug ID: 1854469
Summary: Deprecate SSSD's version of libwbclient
Product: Fedora
Version: rawhide
Status: NEW
Component: sssd
Assignee: sssd-maintainers(a)lists.fedoraproject.org
Reporter: atikhono(a)redhat.com
QA Contact: extras-qa(a)fedoraproject.org
CC: abokovoy(a)redhat.com, atikhono(a)redhat.com,
jhrozek(a)redhat.com, lslebodn(a)redhat.com,
mzidek(a)redhat.com, pbrezina(a)redhat.com,
rharwood(a)redhat.com, sbose(a)redhat.com,
ssorce(a)redhat.com,
sssd-maintainers(a)lists.fedoraproject.org
Target Milestone: ---
Link ID: Github SSSD/sssd/issues/5230
Classification: Fedora
Recent version of Samba requires that winbindd is running to handle the
communication with AD. SSSD's implementation of libwbclient cannot be used
anymore in this case and should be deprecated so that the related code can be
removed in a later version.
This change preferably should be included in F33.
For additional details please see https://github.com/SSSD/sssd/issues/5230
--
You are receiving this mail because:
You are on the CC list for the bug.
You are the assignee for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=1669607
--- Comment #12 from Robbie Harwood <rharwood(a)redhat.com> ---
> Expired tickets are only useful to attackers, so there's absolutely no reason to keep them around.
That's... more reductionist than I think is accurate.
krb5 does change behavior based on the presence of tickets, expired or no. For
instance, consider a collection with credentials for REDHAT.COM and
IPA.REDHAT.COM (in that order). For hostname.redhat.com, the credential for
REDHAT.COM will typically be preferred, even if it's expired. Pruning the
credential for REDHAT.COM will cause the one for IPA.REDHAT.COM to be used
instead. In that case, pruning is desirable (and for this reason, Simo has
been in favor of it I believe).
However, consider instead the same setup with REDHAT.COM and FEDORAPROJECT.ORG.
Pruning expired REDHAT.COM will cause FEDORAPROJECT.ORG's credential to be
attempted. While this will obviously not work (no cross realm there), the
errors will be confusing to a user who doesn't realize the REDHAT.COM
credential has been expired (and there's nothing krb5 can do about it because
the ccache expired it out from under us). And it's potentially even more
confusing when cross-realm relationships come into play.
Upstream's position is that the second case is more typical, so in-tree ccache
backends (FILE, DIR, MEMORY, etc.) do not prune. KEYRING prunes.
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=1669607
--- Comment #11 from Florian Weimer <fweimer(a)redhat.com> ---
(In reply to Pavel Březina from comment #10)
> This seems to be corresponding upstream ticket:
> https://github.com/SSSD/sssd/issues/3593
It's perhaps related, but slightly different. Expired tickets are only useful
to attackers, so there's absolutely no reason to keep them around. Purging
tickets on session end might impact some workflows negatively.
--
You are receiving this mail because:
You are the assignee for the bug.
https://bugzilla.redhat.com/show_bug.cgi?id=1754624
Pavel Březina <pbrezina(a)redhat.com> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |CLOSED
Resolution|--- |WONTFIX
Last Closed| |2020-07-08 11:33:38
--- Comment #3 from Pavel Březina <pbrezina(a)redhat.com> ---
There is a PR for the 'enabled' option Lukas mentioned:
https://github.com/SSSD/sssd/pull/5213
I'm going to close this RFE BZ. Once the PR is merged and released in Fedora,
you'll be enable to just drop in domain to /etc/sssd/sssd.conf and enable them
via this attribute.
If you want to track the status of the PR in this BZ, feel free to reopen it
and change the description to reflect it.
--
You are receiving this mail because:
You are the assignee for the bug.