Bug 733303

^ I didn't write any password , this message was shown right away

One more detail: 

This behaviour occurs if you are trying to start s-c-firewall after `su - user` command.

Steps to reproduce:

1. su - user
2. system-config-firewall


Actual results:
org.fedoraproject.slip.dbus.service.PolKit.NotAuthorizedException.org.fedoraproject.config.firewall.auth:

Expected results:
no error and it should ask for root passwd

This request was evaluated by Red Hat Product Management for
inclusion in the current release of Red Hat Enterprise Linux.
Because the affected component is not scheduled to be updated
in the current release, Red Hat is unfortunately unable to
address this request at this time. Red Hat invites you to
ask your support representative to propose this request, if
appropriate and relevant, in the next release of Red Hat
Enterprise Linux. If you would like it considered as an
exception in the current release, please ask your support
representative.

This is a generic policykit problem.

Here is an example:
"udisks --mount /dev/sr0" is working locally, but not using a remote ssh
connection and also not after the use of "su - <user>".

Assigning to polikit.

This request was evaluated by Red Hat Product Management for
inclusion in the current release of Red Hat Enterprise Linux.
Because the affected component is not scheduled to be updated
in the current release, Red Hat is unfortunately unable to
address this request at this time. Red Hat invites you to
ask your support representative to propose this request, if
appropriate and relevant, in the next release of Red Hat
Enterprise Linux. If you would like it considered as an
exception in the current release, please ask your support
representative.

This request was evaluated by Red Hat Product Management for
inclusion in the current release of Red Hat Enterprise Linux.
Because the affected component is not scheduled to be updated
in the current release, Red Hat is unable to address this
request at this time.

Red Hat invites you to ask your support representative to
propose this request, if appropriate, in the next release of
Red Hat Enterprise Linux.

Thanks for your report.

For ssh, the ultimate problem is #613796; there is no "session" associated with the SSH login, so it's not possible to prompt for root passwords.  You can still configure the policy to allow access to unprivileged users to logging in through ssh (through ResultAny=yes in a .pkla file), but prompting for passwords is impossible.

In (su -) case, the new shell does not have XDG_SESSION_COOKIE set, and is therefore not considered a part of a session.  Adding pam_ck_session_connector to /etc/pam.d/su-l sets up a session for the shell, but it's a separate session (in particular it's not treated as an active session /dev/pts/N is not related to the active VT).  Still, it's possible to configure the firewall policy to prompt for passwords in inactive sessions (e.g. again using a .pkla file), and to run a separate copy of polkit-gnome-authentication-agent-1).  Then starting system-config-firewall will cause a password prompt to appear.


In summary:
* ssh: Already reported in #613796 (and WONTFIXed)

* Individual application policy having <allow_any>no</allow_inactive>, making polkit privilege escallation mechanisms for remote sessions: There is no definite policy documentation, however this is widespread existing practice.  In any case, we can't incompatibly change the defaults within the lifetime of RHEL6.  So WONTFIX.

* (su -): ConsoleKit does not track session information through this invocation, and arguably should (and with audit enabled in the RHEL kernel build, it seems possible).

So reassigning for ConsoleKit to possibly handle the (su -) case.

This request was evaluated by Red Hat Product Management for
inclusion in the current release of Red Hat Enterprise Linux.
Because the affected component is not scheduled to be updated
in the current release, Red Hat is unable to address this
request at this time.

Red Hat invites you to ask your support representative to
propose this request, if appropriate, in the next release of
Red Hat Enterprise Linux.

(In reply to Miloslav Trmač from comment #12)
> * (su -): ConsoleKit does not track session information through this
> invocation, and arguably should (and with audit enabled in the RHEL kernel
> build, it seems possible).

Putting aside that I don't know how would I go about doing this. I think this can't generally work because whether audit is enabled or not can be configured on kernel command line.

> 
> So reassigning for ConsoleKit to possibly handle the (su -) case.

I think that the most simple solution is to not unset XDG_SESSION_COOKIE environment variable. In case this can't be done then we should close this as CANTFIX. Reassigning to util-linux-ng.

There is "su --preserve-environment", but it's mutually exclusive to --login (su -). The --login purpose is to *reset* all.

Note that old su(1) versions are maintained in coreutils.

Closing as CANTFIX, I don't see elegant way how to fix it (maybe on Fedora you can use "machinectl shell", but I didn't test it).