I’m not using the Default Trust View. This is a brand new trust view.

David Eddleman

On 8/29/17, 8:02 AM, "Sumit Bose via FreeIPA-users" freeipa-users@lists.fedorahosted.org wrote:

On Mon, Aug 28, 2017 at 04:39:46PM +0000, 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

I'm pretty sure this works as expected with the 'Default Trust View'. I'll try to reproduce with a non-default view.

bye, Sumit

> > 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? > > David Eddleman

> _______________________________________________ > FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org > To unsubscribe send an email to freeipa-users-leave@lists.fedorahosted.org _______________________________________________ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-leave@lists.fedorahosted.org

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.

I attempted this. Logged in as my user, saw that the defaults were being applied. Logged out, expired the cache, and logged back in with the same non-defined shell and GECOS field.

FYI: the user being logged in is an AD user from an AD one-way trust with the IPA domain.

David Eddleman

On 8/29/17, 10:56 AM, "Sumit Bose via FreeIPA-users" freeipa-users@lists.fedorahosted.org wrote:

On Tue, Aug 29, 2017 at 06:11:43PM +0300, Alexander Bokovoy wrote: > 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.

Yes, this is my understanding about SSSD should behave as well.

bye, Sumit

> > -- > / Alexander Bokovoy _______________________________________________ FreeIPA-users mailing list -- freeipa-users@lists.fedorahosted.org To unsubscribe send an email to freeipa-users-leave@lists.fedorahosted.org