On ti, 29 elo 2017, Sumit Bose via FreeIPA-users wrote:
On Tue, Aug 29, 2017 at 05:00:06PM +0300, Alexander Bokovoy via FreeIPA-users 
wrote:
On ma, 28 elo 2017, Eddleman, David via FreeIPA-users wrote:
> So I've created a ID override on the IPA master called "TestShellView"
> to test out changing per-user requirements for shells.
>
> Verify the ID override on the master:
> [root@ipamaster01 ~]# ipa idoverrideuser-find TestShellView
> --------------------------
> 1 User ID override matched
> --------------------------
>  Anchor to override: user@domain
>  GECOS: TEST ID VIEW
>  Login shell: /bin/ksh
> ----------------------------
> Number of entries returned 1
> ----------------------------
>
> Good, looks as expected. I also tested the GECOS override just in case such a 
thing was needed in the future.
>
> [root@rhel7template ~]# getent passwd user@domain
> user@domain:*:689709720:689709720:TEST ID VIEW:/home/domain/user:/bin/ksh
>
> Looks good. It's doing what it's supposed to be doing.
> So now we remove the GECOS and shell settings in the webUI and verify via CLI 
that they're gone:
>
> [root@ipamaster01 ~]# ipa idoverrideuser-find TestShellView
> --------------------------
> 1 User ID override matched
> --------------------------
>  Anchor to override: user@domain
> ----------------------------
> Number of entries returned 1
> ----------------------------
>
> Still good so far. No overrides defined.
>
> Clear the cache to verify that the data is fresh.
>
> [root@rhel7template ~]# sss_cache -E
> [root@rhel7template ~]# getent passwd user@domain
> user@domain:*:689709720:689709720:TEST ID VIEW:/home/domain/user:/bin/ksh
>
> That's not right...
> The default and fallback don't call for ksh either:
>
> [root@rhel7template ~]# cat /etc/sssd/sssd.conf | grep shell
> allowed_shells = /bin/bash,/bin/sh,/bin/ksh
> shell_fallback = /sbin/nologin
> default_shell = /bin/bash
>
> So let's try purging the cache files...
> [root@rhel7template ~]# cd /var/lib/sss/db/
> [root@rhel7template db]# ls
> <cache file listing>
> [root@rhel7template db]# rm -f *
> [root@rhel7template db]# ls
> [root@rhel7template db]# service sssd restart
> Redirecting to /bin/systemctl restart sssd.service
> [root@rhel7template db]# getent passwd user@domain
> user@domain:*:689709720:689709720:Username:/home/domain/user:/bin/bash
>
> Now it's showing what it's supposed to.
>
> This shouldn't be happening. If we have to purge sss cache files each
> time we make an ID Override change, this won't work. Is this expected
> behavior, or is this a bug?
You should not need to expire SSSD cache. However, it is by design that
ID overrides only change with SSSD restart. The reason for that is
because in POSIX environment one cannot change already running processes
where UID/GID set by the kernel at session login time. Changing SSSD's
view of the ID View/overrides on the fly also means inconsistence of the
access controls for file systems. SSSD does read and refresh ID view
which applies to the specific host on its startup so a restart is
enough.

Yes, but this is only for a complete change of the view e.g. from viewA
to viewB. Individual changes in the user overrides of the current view
should be made available if the cached entry expires. There is of course
the risk to change the UID or GID at runtime of a single user. But on
the other hand changing e.g. the default shell of a user would be
cumbersome.
Yes. I think we should not conflate multiple things into one "yes/no"
answer, though. Below is my attempt to have a simple explanation, let me
know if this is right or wrong from the SSSD point of view:

Changing which ID view is applied to the host requires SSSD restart.

Changing user properties within ID view is applied when user information
is expired in SSSD cache. In practice, an easiest way to apply that is
by doing a new user session because on authentication SSSD does refresh
user's information. Another way is to use sss_cache utility for an
individual user (sss_cache -u username).

These are two simple rules right now.
--
/ Alexander Bokovoy
_______________________________________________
FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org
To unsubscribe send an email to freeipa-users-le...@lists.fedorahosted.org

Reply via email to