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
Just to add.. I couldn't see any errors in /var/log/messages nor /var/log/secure.
Were you perhaps running this from a terminal? It may be that the realm cannot authorize via polkit from a terminal.
(In reply to comment #2) > Were you perhaps running this from a terminal? Er, I meant a VT? ie: not in X.
Yes, I was executing those commands in the ssh session. But the "pkexec bash" worked, is that something different?
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?
(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.
(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...)
(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?
(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).
*** Bug 955501 has been marked as a duplicate of this bug. ***
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.
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.
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.