On Tue, 24 Nov 2015, Winfried de Heiden wrote:
Hi all,
The problem is clear, there is a misunderstanding of the service "su"
and "su-l", this is about the target users. Hence; su - to user
winfried is allowed since su and su-l are added to the hbac service
list of this user.
This looks a bit strange from the ui perspective, all other HBAC
services are what this user is allow to do; "su" and "su-l" defines
that OTHER user may become this user by using su.
A bit strange, but this is how is works. Anyone disagree?
Consider the fact that HBAC names are names of PAM services used by
applications. If an application uses PAM, it specifies name of own
configuration file relative to /etc/pam.d toPAM API.
For 'su' utility look into its manual page, section FILES:
FILES
/etc/pam.d/su default PAM configuration file
/etc/pam.d/su-l PAM configuration file if --login is specified
/etc/default/su command specific logindef config file
/etc/login.defs global logindef config file
'su' utility uses two different PAM names for different modes of
operation. Therefore, when defining HBAC rules for 'su' you need to take
into account both PAM services and decide what you want to do with them.
Winny
Op 24-11-15 om 14:04 schreef Jakub Hrozek:
On Tue, Nov 24, 2015 at 12:58:42PM +0100, Winfried de Heiden wrote:
Hi all,
[winfried@ipa ~]$ ipa hbacrule-show allow_all
Rule name: allow_all
User category: all
Host category: all
Service category: all
Description: Allow all users to access any host from any host
Enabled: FALSE
[winfried@ipa ~]$ ipa hbacrule-show testuser
Rule name: testuser
Enabled: TRUE
Users: testuser
Hosts: fedora23-server.blabla.bla
Services: sshd
[winfried@ipa ~]$ ipa user-show winfried
User login: winfried
First name: Winfried
Last name: de Heiden
Home directory: /home/winfried
Login shell: /bin/bash
etc. .etc.
[winfried@ipa ~]$ ipa user-show testuser
User login: testuser
First name: test
Last name: user
Home directory: /home/testuser
Login shell: /bin/bash
Email address: testu...@blabla.bla
UID: 10005
GID: 10005
Account disabled: False
Password: True
Member of groups: ipausers
Member of HBAC rule: testuser
Kerberos keys available: True
[[testuser@fedora23-server ~]$ su winfried
Wachtwoord:
[winfried@fedora23-server testuser]$ id
UID=10001(winfried) GID=10001(winfried)
groepen=10001(winfried),10000(admins),10003(linuxadmins),10004(linuxusers)
context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
So yes, I can su to another IPA-user :(
sssd_pam now shows information, but nothing seems to go wrong...
I think you forgot to CC freeipa-users.
In this case, can you look into /var/log/secure again and into the
domain logs?
What's happening?
Winny
Op 24-11-15 om 11:43 schreef Jakub Hrozek:
On Tue, Nov 24, 2015 at 11:10:11AM +0100, Winfried de Heiden wrote:
Hi all,
Running as an ordinary user, straight from the beginning.
Is the (default) suid of/usr/bin/su causing this?
Anyway: the info requested:
/var/log/secure will tell:
Nov 24 11:04:11 fedora23-server su: pam_systemd(su:session): Cannot create
session: Already running in a session
Nov 24 11:04:11 fedora23-server su: pam_unix(su:session): session opened
for user root by testuser(uid=10005)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Sorry, I missed this previously. So you're running "su -" as testuser
right? That's not hitting SSSD, because the target user is root, so "su"
would do:
pam_start("su", "root", ...)
pam_authenticate();
So what you're seeing is expected. Try su-ing to testuser from another
non-root user, it's going to fail.
--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project
--
/ Alexander Bokovoy
--
Manage your subscription for the Freeipa-users mailing list:
https://www.redhat.com/mailman/listinfo/freeipa-users
Go to http://freeipa.org for more info on the project
