Issue #2081: [RFE] sss_cache: invalidate sudo rules - sssd

This might be possible when we have the dbus api and are able to signal the sudo responder in a meaningful and authenticated way..

milestone: SSSD 1.13 beta => SSSD 1.13 backlog
priority: major => critical

Re-setting priority of 1.13 backlog tickets used for planning.

priority: critical => major

pbrezina commented 9 years ago

This ticket should consist from two steps:

1) Invalidate sudo rules by setting expiration time to 0 -- simple by modifying sysdb
2) Provide a way to perform full refresh on demand -- maybe with dbus, allowed only by root

sensitive: => 0

Fields changed

owner: somebody => pcech

Replying to [comment:7 pbrezina]:

This ticket should consist from two steps:

1) Invalidate sudo rules by setting expiration time to 0 -- simple by modifying sysdb
2) Provide a way to perform full refresh on demand -- maybe with dbus, allowed only by root

Should we rather rely on native ipa sudo rovider?
then we could skip the 2nd step.

Fields changed

cc: => lslebodn@redhat.com

pbrezina commented 9 years ago

Hmm, trac didn't send me any notice, sorry for late reply. 1) We can't rely on any specific provider. 2) IPA provider won't solve this.

Fields changed

cc: lslebodn@redhat.com => lslebodn@redhat.com, pbrezina@redhat.com

I talked with pbrezina.

There could be different providers which manage sudo rules (LDAP, IPA, AD). We need to use appropriate provider to make full refresh of sudo rules. So we cannot only use native IPA sudo provider. DBUS seems to be good way how to inform the provider that we need to do full refresh.

I agree with pbrezina' two steps (comment:7) and I think step b) could by covered by next ticket.

Replying to [comment:13 pcech]:

I talked with pbrezina.

There could be different providers which manage sudo rules (LDAP, IPA, AD). We need to use appropriate provider to make full refresh of sudo rules. So we cannot only use native IPA sudo provider. DBUS seems to be good way how to inform the provider that we need to do full refresh.

What does it mean DBUS seems to good way?

We do not start IFP provider by default.

Replying to [comment:14 lslebodn]:

We do not start IFP provider by default.

We don't need to, it's a DBUS service, it can be (and should be) started on demand.

Replying to [comment:15 jhrozek]:

Replying to [comment:14 lslebodn]:

We do not start IFP provider by default.

We don't need to, it's a DBUS service, it can be (and should be) started on demand.
It does not work for me.

[root@host ~]# systemctl stop sssd
[root@host ~]# rm -f /var/lib/sss/db/*

[root@host ~]# systemctl start sssd

[root@host ~]# getent passwd lslebodn
lslebodn:x:20728:20728:Lukas Slebodnik:/home/lslebodn:/bin/bash

[root@host ~]# systemctl status sssd
● sssd.service - System Security Services Daemon
   Loaded: loaded (/usr/lib/systemd/system/sssd.service; disabled; vendor preset: disabled)
  Drop-In: /etc/systemd/system/sssd.service.d
           └─journal.conf, valgrind.conf
   Active: active (running) since Tue 2015-11-24 16:24:15 CET; 15s ago
  Process: 4108 ExecStart=/usr/sbin/sssd -D -f (code=exited, status=0/SUCCESS)
 Main PID: 4134 (sssd)
   CGroup: /system.slice/sssd.service
           ├─4134 /usr/sbin/sssd -D -f
           ├─4135 /usr/libexec/sssd/sssd_be --domain example.com --uid 0 --gid 0 --debug-to-files
           ├─4136 /usr/libexec/sssd/sssd_nss --uid 0 --gid 0 --debug-to-files
           └─4137 /usr/libexec/sssd/sssd_pam --uid 0 --gid 0 --debug-to-files
^C
[root@host ~]# time gdbus call --system --dest org.freedesktop.sssd.infopipe --object-path /org/freedesktop/sssd/infopipe --method org.freedesktop.sssd.infopipe.GetUserGroups 'lslebodn'
Error: GDBus.Error:org.freedesktop.DBus.Error.TimedOut: Failed to activate service 'org.freedesktop.sssd.infopipe': timed out

real    0m25.017s
user    0m0.004s
sys     0m0.003s

It only works for me with "ifp" in services.

I didn't say it works already, I said this is how it should work :-)

Replying to [comment:17 jhrozek]:

I didn't say it works already, I said this is how it should work :-)
So if we decided to use dbus then this ticket should be blocked by ticket for starting ifp on demand.

Replying to [comment:18 lslebodn]:

Replying to [comment:17 jhrozek]:

I didn't say it works already, I said this is how it should work :-)
So if we decided to use dbus then this ticket should be blocked by ticket for starting ifp on demand.

Maybe, but not yet, we must write design first. It's better to do the design through proper channels - design page and discussion on list, not in the ticket.

pbrezina commented 9 years ago

Nobody is talking about using IFP. Backend itself has a D-Bus interface we can connect to the same way as responders do.

We agreed with Petr that this ticket is going to be split into two. One will only invalidate rules via sss_cache by setting expiration timestamp to zero, this can be done now.

The second part will implement a way to trigger full refresh (and maybe even smart refresh) on desire. This will be done by calling a backend D-Bus method. In my opinion, this should be added into sssctl tool which Pavel is going to work on. Before we do this I will improve our backend dbus interface to take advantage of new sbus features as a prerequisite to this feature.

That's good plan.

Ah, sorry, I thought this was going to be the same public D-Bus API as we were going to use for the sssctl status tool.

Fields changed

description: Currently sss_cache can't be used to reliably invalidate sudo rules. We should add that support. => Currently sss_cache can't be used to reliably invalidate sudo rules. We should add that support.

UPDATE

This ticket was split to two tickets.
Second part is #2884

Updated goal:
Invalidate sudo rules by setting expiration time to 0 -- simple by modifying sysdb.

Thanks, feel free to also move this ticket to 1.14 alpha, the backlogs is something we will reconsider later for work on 1.14, but 1.13 is more or less in bugfixing mode now.