Bug 733303 - cannot start s-c-firewalll like a nonroot
Summary: cannot start s-c-firewalll like a nonroot
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: util-linux-ng
Version: 6.1
Hardware: Unspecified
OS: Unspecified
high
high
Target Milestone: rc
: ---
Assignee: Karel Zak
QA Contact: qe-baseos-daemons
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2011-08-25 12:14 UTC by Petr Sklenar ⛄
Modified: 2015-11-25 10:24 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2015-11-25 10:24:30 UTC


Attachments (Terms of Use)
screenshot of error (412.45 KB, image/png)
2011-08-25 12:14 UTC, Petr Sklenar ⛄
no flags Details

Description Petr Sklenar ⛄ 2011-08-25 12:14:38 UTC
Created attachment 519831 [details]
screenshot of error

Description of problem:
cannot start s-c-firewalll like a nonroot

Version-Release number of selected component (if applicable):
system-config-firewall-1.2.27-5.el6.noarch

How reproducible:
deterministic

Steps to Reproduce:
1. ssh nonroot@whatever_machine -XC
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 

Additional info:

Comment 1 Petr Sklenar ⛄ 2011-08-25 12:20:01 UTC
^ I didn't write any password , this message was shown right away

Comment 3 Alex Sersen 2011-08-25 12:40:59 UTC
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

Comment 4 RHEL Product and Program Management 2011-08-25 12:49:06 UTC
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.

Comment 5 Thomas Woerner 2011-08-25 14:19:18 UTC
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.

Comment 7 Suzanne Yeghiayan 2012-02-14 23:14:28 UTC
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.

Comment 8 RHEL Product and Program Management 2012-09-18 18:31:25 UTC
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.

Comment 12 Miloslav Trmač 2013-04-23 14:53:21 UTC
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.

Comment 13 RHEL Product and Program Management 2013-10-14 01:01:02 UTC
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.

Comment 14 Michal Sekletar 2015-10-14 11:04:26 UTC
(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.

Comment 15 Karel Zak 2015-11-25 10:24:30 UTC
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).


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