Bug 967036

Summary: [RFE]realmd cannot join a domain executed under local user account
Product: Red Hat Enterprise Linux 7 Reporter: Patrik Kis <pkis>
Component: realmdAssignee: Stef Walter <stefw>
Status: CLOSED WONTFIX QA Contact: Patrik Kis <pkis>
Severity: medium Docs Contact:
Priority: medium    
Version: 7.1Keywords: FutureFeature
Target Milestone: rc   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of: 867807 Environment:
Last Closed: 2015-04-14 10:06:52 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On: 867807, 959864    
Bug Blocks:    

Description Patrik Kis 2013-05-24 14:43:45 UTC
+++ This bug was initially created as a clone of Bug #867807 +++

Description of problem:

cannot join the domain when the command is executed with local user account
I was following https://fedoraproject.org/wiki/QA:Testcase_Active_Directory_realmd_join_sssd

This can be done with root account  (and permissive mode because of selinux issues)

[test@dhcp-25-148 ~]$ id
uid=1001(test) gid=1001(test) groups=1001(test),10(wheel) context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
[test@dhcp-25-148 ~]$ TESTDOMAIN=RADI08.SEGAD.LAB.SJC.REDHAT.COM
[test@dhcp-25-148 ~]$ realm join --verbose --user=Leela $TESTDOMAIN
 * Searching for kerberos SRV records for domain: _kerberos._udp.radi08.segad.lab.sjc.redhat.com
 * Searching for MSDCS SRV records on domain: _kerberos._tcp.dc._msdcs.radi08.segad.lab.sjc.redhat.com
 * ad1.radi08.segad.lab.sjc.redhat.com:88 
 * Found kerberos DNS records for: radi08.segad.lab.sjc.redhat.com
 * Found AD style DNS records for: radi08.segad.lab.sjc.redhat.com
 * Successfully discovered: radi08.segad.lab.sjc.redhat.com
Password for Leela: 
realm: Couldn't join realm: Not authorized to perform this action
[test@dhcp-25-148 ~]$ 
[test@dhcp-25-148 ~]$ 
[test@dhcp-25-148 ~]$ 
[test@dhcp-25-148 ~]$ pkexec bash
[test@dhcp-25-148 ~]$ pkexec bash
==== AUTHENTICATING FOR org.freedesktop.policykit.exec ===
Authentication is needed to run `/usr/bin/bash' as the super user
Multiple identities can be used for authentication:
 1.  karel
 2.  test
Choose identity to authenticate as (1-2): 2
Password: 
==== AUTHENTICATION COMPLETE ===
[root@dhcp-25-148 ~]# exit
[test@dhcp-25-148 ~]$ 
[test@dhcp-25-148 ~]$ sudo pkcheck --action-id org.freedesktop.realmd.configure-realm --process $$ --allow-user-interaction
Not authorized.


Version-Release number of selected component (if applicable):

polkit-0.107-4.fc18.i686
package sssd is not installed
realmd-0.9-1.fc18.i686

--- Additional comment from Karel Srot on 2012-10-18 08:38:45 EDT ---

Just to add.. I couldn't see any errors in /var/log/messages nor /var/log/secure.

--- Additional comment from Stef Walter on 2012-10-19 01:56:13 EDT ---

Were you perhaps running this from a terminal? It may be that the realm cannot authorize via polkit from a terminal.

--- Additional comment from Stef Walter on 2012-10-19 01:57:19 EDT ---

(In reply to comment #2)
> Were you perhaps running this from a terminal? 

Er, I meant a VT? ie: not in X.

--- Additional comment from Karel Srot on 2012-10-19 03:54:39 EDT ---

Yes, I was executing those commands in the ssh session. But the "pkexec bash" worked, is that something different?

--- Additional comment from Stef Walter on 2012-10-19 04:23:30 EDT ---

It  builds its own PolkitTextListener agent in. It seems rather complicated, for example here's how systemd's systemctl did it:

http://cgit.freedesktop.org/systemd/systemd/commit/?id=6bb92a169e8a65e7def5545798001e0dbecc7d4f

David, does every command line tool really have to go through all of that?

--- Additional comment from David Zeuthen on 2012-10-22 10:21:03 EDT ---

(In reply to comment #5)
> It  builds its own PolkitTextListener agent in. It seems rather complicated,
> for example here's how systemd's systemctl did it:
> 
> http://cgit.freedesktop.org/systemd/systemd/commit/
> ?id=6bb92a169e8a65e7def5545798001e0dbecc7d4f
> 
> David, does every command line tool really have to go through all of that?

Yes - but I don't think "all of that" is that much work. Unless you count 44 insertions, 2 deletions as "all of that":

 http://cgit.freedesktop.org/polkit/commit/src/programs/pkexec.c?id=42177383585e1e01cd6150f891176afcd4538a82

That said, there's a tool to make it easier

 http://www.freedesktop.org/software/polkit/docs/latest/pkttyagent.1.html

but if you're already using the GLib-based client-side libraries not sure it's going to help you much.

Hope this helps.

--- Additional comment from David Zeuthen on 2012-10-22 10:29:27 EDT ---

(The alternative is that we start an authentication agent instance for _every_ ssh login. That'd totally work too but I'm pretty sure people wouldn't like it. Don't like it. We could also play games like forwarding requests to the polkit auth agent on the other side of the ssh connection but not sure that's a good idea either...)

--- Additional comment from Stef Walter on 2012-10-22 10:37:52 EDT ---

(In reply to comment #6)
> (In reply to comment #5)
> > It  builds its own PolkitTextListener agent in. It seems rather complicated,
> > for example here's how systemd's systemctl did it:
> > 
> > http://cgit.freedesktop.org/systemd/systemd/commit/
> > ?id=6bb92a169e8a65e7def5545798001e0dbecc7d4f
> > 
> > David, does every command line tool really have to go through all of that?
> 
> Yes - but I don't think "all of that" is that much work. Unless you count 44
> insertions, 2 deletions as "all of that":
> 
>  http://cgit.freedesktop.org/polkit/commit/src/programs/pkexec.
> c?id=42177383585e1e01cd6150f891176afcd4538a82

Well this is very different than what systemd did.

> Hope this helps.

Sorta, but the client is not setuid. It's not like pkexec where the terminal client is authorizing the action. The realmd process is authorizing the action, and the client 'realm' is calling realmd over dbus. Would the above pkexec change apply?

--- Additional comment from David Zeuthen on 2012-10-22 10:44:23 EDT ---

(In reply to comment #8)
> Sorta, but the client is not setuid. It's not like pkexec where the terminal
> client is authorizing the action. The realmd process is authorizing the
> action, and the client 'realm' is calling realmd over dbus. Would the above
> pkexec change apply?

Sure - any process can be a polkit authentication agent for any other process owned by the same uid (ditto session).

--- Additional comment from Stef Walter on 2013-04-29 12:49:36 EDT ---

Comment 1 Stef Walter 2013-05-27 09:53:04 UTC
I have no plans to fix this for RHEL 7.0. It is unlikely to be fixed. In order to accomplish this I need to fix Polkit and various other bits. 

Not a priority in my opinion. 

This bug tells the user they are not authorized. The typical sysadmin response to such an error is to run become root or run the command as sudo. This solves the issue.

Running system commands as non-root users, and being prompted for privilege escalation is a nice touch. As of now this works from within a terminal running in a GUI desktop, but not when ssh'd into the machine or using a VT.

But again this deficiency does not detract from the experience, is not core functionality and in my opinion too invasive to fix for RHEL 7.0 at this point.

Comment 2 Patrik Kis 2013-05-27 11:15:40 UTC
(In reply to Stef Walter from comment #1)
> I have no plans to fix this for RHEL 7.0. It is unlikely to be fixed. In
> order to accomplish this I need to fix Polkit and various other bits. 
> 
> Not a priority in my opinion. 
> 
> This bug tells the user they are not authorized. The typical sysadmin
> response to such an error is to run become root or run the command as sudo.
> This solves the issue.
> 
> Running system commands as non-root users, and being prompted for privilege
> escalation is a nice touch. As of now this works from within a terminal
> running in a GUI desktop, but not when ssh'd into the machine or using a VT.
> 
> But again this deficiency does not detract from the experience, is not core
> functionality and in my opinion too invasive to fix for RHEL 7.0 at this
> point.

I must agree; this is not a priority at all.
But what maybe could be fixed in RHEL-7.0 is to reject realm join immediately when a non privileged user runs it.

I'm keeping this bug opened for RHEL-7.1 and opened a new one for RHEL-7.0 for the immediate reject: bug 967530.

Comment 3 Stef Walter 2013-05-27 11:22:28 UTC
(In reply to Patrik Kis from comment #2)
> (In reply to Stef Walter from comment #1)
> > I have no plans to fix this for RHEL 7.0. It is unlikely to be fixed. In
> > order to accomplish this I need to fix Polkit and various other bits. 
> > 
> > Not a priority in my opinion. 
> > 
> > This bug tells the user they are not authorized. The typical sysadmin
> > response to such an error is to run become root or run the command as sudo.
> > This solves the issue.
> > 
> > Running system commands as non-root users, and being prompted for privilege
> > escalation is a nice touch. As of now this works from within a terminal
> > running in a GUI desktop, but not when ssh'd into the machine or using a VT.
> > 
> > But again this deficiency does not detract from the experience, is not core
> > functionality and in my opinion too invasive to fix for RHEL 7.0 at this
> > point.
> 
> I must agree; this is not a priority at all.
> But what maybe could be fixed in RHEL-7.0 is to reject realm join
> immediately when a non privileged user runs it.

The actual Join() command will return as unauthorized immediately if the caller is not authorized. However 'realm join' does a Discover() first, which by default does not require special privileges. So it's not trivial to add a hack to detect the fact that Join() will fail before we've run Discover().

Comment 4 Patrik Kis 2013-05-28 07:18:28 UTC
> 
> The actual Join() command will return as unauthorized immediately if the
> caller is not authorized. However 'realm join' does a Discover() first,
> which by default does not require special privileges. So it's not trivial to
> add a hack to detect the fact that Join() will fail before we've run
> Discover().

I see. It has really low priority; it would just give a little more comfort for admins but it is not a blocking issue for me.
Feel free to reject the bug 967530, if you think the required change would involve more risk than the result benefit would be.

Comment 5 Stef Walter 2013-07-15 16:04:15 UTC
*** Bug 967530 has been marked as a duplicate of this bug. ***

Comment 6 Stef Walter 2013-08-07 08:13:06 UTC
Agree. Won't be able to fix this for RHEL 7.0, but we should work on this for a later release.

Comment 7 Stef Walter 2015-04-14 10:06:52 UTC
After considering this, it should be WONTFIX.

The user's session should be setup correctly for polkit in order to make use of privilege escalation. If not, then the user can use root or sudo.