This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours
Bug 867807 - realmd cannot join a domain executed under local user account
realmd cannot join a domain executed under local user account
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: realmd (Show other bugs)
19
Unspecified Unspecified
medium Severity medium
: ---
: ---
Assigned To: Stef Walter
Fedora Extras Quality Assurance
:
: 955501 (view as bug list)
Depends On: 959864
Blocks: 967036
  Show dependency treegraph
 
Reported: 2012-10-18 06:28 EDT by Karel Srot
Modified: 2015-04-14 08:03 EDT (History)
5 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 967036 (view as bug list)
Environment:
Last Closed: 2015-02-17 09:31:09 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)


External Trackers
Tracker ID Priority Status Summary Last Updated
FreeDesktop.org 56319 None None None 2012-10-23 06:08:27 EDT

  None (edit)
Description Karel Srot 2012-10-18 06:28:00 EDT
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
Comment 1 Karel Srot 2012-10-18 08:38:45 EDT
Just to add.. I couldn't see any errors in /var/log/messages nor /var/log/secure.
Comment 2 Stef Walter 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.
Comment 3 Stef Walter 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.
Comment 4 Karel Srot 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?
Comment 5 Stef Walter 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?
Comment 6 David Zeuthen 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.
Comment 7 David Zeuthen 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...)
Comment 8 Stef Walter 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?
Comment 9 David Zeuthen 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).
Comment 10 Stef Walter 2013-04-29 12:49:36 EDT
*** Bug 955501 has been marked as a duplicate of this bug. ***
Comment 11 Fedora End Of Life 2015-01-09 12:25:45 EST
This message is a notice that Fedora 19 is now at end of life. Fedora 
has stopped maintaining and issuing updates for Fedora 19. It is 
Fedora's policy to close all bug reports from releases that are no 
longer maintained. Approximately 4 (four) weeks from now this bug will
be closed as EOL if it remains open with a Fedora 'version' of '19'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 19 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.
Comment 12 Fedora End Of Life 2015-02-17 09:31:09 EST
Fedora 19 changed to end-of-life (EOL) status on 2015-01-06. Fedora 19 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.
Comment 13 Stef Walter 2015-04-14 08:03:52 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.