Bug 628862 - On RHEL 6, running "pkaction --action-id" just displays a man page
Summary: On RHEL 6, running "pkaction --action-id" just displays a man page
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: polkit
Version: 6.0
Hardware: All
OS: Linux
medium
medium
Target Milestone: rc
: ---
Assignee: Miloslav Trmač
QA Contact: Martin Žember
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2010-08-31 08:35 UTC by Justin Clift
Modified: 2015-07-13 04:34 UTC (History)
5 users (show)

Fixed In Version: polkit-0.96-6.el6
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2014-10-14 07:27:30 UTC


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2014:1533 normal SHIPPED_LIVE polkit bug fix and enhancement update 2014-10-14 01:21:51 UTC
FreeDesktop.org 29936 None None None Never

Description Justin Clift 2010-08-31 08:35:36 UTC
Description of problem:

In RHEL 6.0, running the pkaction command with the argument --action-id just opens the man page for pkaction.  It doesn't generate a warning, or give any other indication there is something wrong.  It just opens the man page.

The polkit man page *itself* even documents that option as being the thing to use to get a list of the available actions:

  "If called with --action-id then all actions are displayed."


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

  polkit-0.96-2.el6.x86_64


How reproducible:

Every time.


Steps to Reproduce:
1. pkaction --action-id

  
Actual results:

The man page for pkaction is displayed, without any indication of the error.

Not enough arguments? Too many? Something not installed? Something else wrong? WTF?


Expected results:

The list of all actions to be displayed, as documented.


Additional info:

Having a man page displayed when an error occurs, rather than indicating an error, seems fairly non-optimal.

Consider the case where pkaction is called on servers (it is).  If a script calls pkaction like this:

  pkaction --action-id ${ACTION}

and for some reason $ACTION isn't set (script error), then pkaction just caused the script to hang rather than return an error code which can be caught.  :(

Comment 1 David Zeuthen 2010-08-31 21:49:51 UTC
(In reply to comment #0)
> Description of problem:
> 
> In RHEL 6.0, running the pkaction command with the argument --action-id just
> opens the man page for pkaction.  It doesn't generate a warning, or give any
> other indication there is something wrong.  It just opens the man page.
> 
> The polkit man page *itself* even documents that option as being the thing to
> use to get a list of the available actions:
> 
>   "If called with --action-id then all actions are displayed."

That's a bug. It should say "If called with no arguments then all actions are displayed." instead.

> Having a man page displayed when an error occurs, rather than indicating an
> error, seems fairly non-optimal.

No, it's completely fine (and also intentional) to invoke man(1) if the caller is invoking the program incorrectly.

> Consider the case where pkaction is called on servers (it is)

I'm curious, who's doing that? And why?

> .  If a script
> calls pkaction like this:
> 
>   pkaction --action-id ${ACTION}
> 
> and for some reason $ACTION isn't set (script error), then pkaction just caused
> the script to hang rather than return an error code which can be caught.  :(

If the user has buggy scripts where e.g. they don't check for $ACTION then all bets are really off.

First, sure, there's a bug here with the man page - it should say "If called with no arguments then all actions are displayed." as I agreed to above.

Second, we should probably avoid invoking man(1) if stdin isn't a tty. As a side-effect, that would actually fix your problem, yes? I'm surprised man(1) simply doesn't bail if this is the case.

Comment 2 Justin Clift 2010-09-01 05:59:22 UTC
pkaction is being called by the libvirt daemon (libvirtd), for authenticating remote users to the libvirt management socket.

It's being used to check if the user in question should have the ability to manage libvirt.  (I'm presently writing docs around this area)

Added Dan Berrange to the CC list, as he wrote the integration code. :)

Having pkaction check if it's being called from a tty is probably a step in the right direction.

Seems like an strange amount of effort to go to for this specific use case, when instead you could just print out "pkaction: incorrect number of arguments given".

For example, other ways of calling pkaction "incorrectly" don't result in this man page:

  # pkaction --action-id foo bar baz
  No action with action id foo
  #

  # pkaction --action-id --action-id foo
  No action with action id --action-id
  #

More bugs? :/

Having incorrect usage of a command automatically launch a man page, without telling the user that's why the man page was launched, is very user unfriendly. :(  (Is it an attempt to be user friendly, or it is attempting to be smart, etc?)

Saying this because it did this to me, I first went and checked with other people that they too get this behaviour.  (ie it wasn't just my system)  That's how unexpected and bizarre a behaviour it is.  And *at no point* did it indicate it was due to an error on my part.

For all I knew, it was due to a misconfiguration of pkaction or _some other app_ itself.

Comment 3 David Zeuthen 2010-09-01 12:41:05 UTC
pkaction(1) is definitely not intended to be called from programs - it is intended solely as an interactive sysadmin tool. That's also why the behavior / failure mode isn't very well defined. We might also change the options/arguments so any program relying on it might break.

For the record, if a program is calling pkaction(1) that program is likely buggy. This is because there really is no need for any program to know about actions (they should know implicitly about the actions they register themselves). That's the idea anyway, I'm not opposed to improving the docs. But RH bugzilla is the wrong place for such a discussion, please file it upstream at bugs.freedesktop.org.

pkcheck(1), however, is intended to be invoked by programs (not only admins) so the behavior there is a lot more well-defined and we provide guarantees that we won't break anything etc. (only add new options etc.).

So I think (and hope) you are mistaken that libvirt is using pkaction(1).

> Having incorrect usage of a command automatically launch a man page,
> without telling the user that's why the man page was launched, is
> very user unfriendly.

I disagree.

> (Is it an attempt to be user friendly, or it is attempting
> to be smart, etc?)

It's an attempt to be user friendly.

Comment 4 Justin Clift 2010-09-01 13:28:40 UTC
Apologies, you're correct with regards to pkcheck vs pkaction.  libvirt uses pkcheck.

My subsequent looking into what the "pkcheck" thing turning up in the logs is, led me to pkaction.  And I got confused there at some point. :/


> pkaction(1) is definitely not intended to be called from programs - it is
> intended solely as an interactive sysadmin tool.

Ok.  That's kind of not the *nix programming model I'm familiar with, where command line tools (unless interactive in the ncurses way) generally get incorporated into scripting.  But, it's your util, not mine. ;)

Is there absolutely no scope for management utils or similar to use pkaction for querying actions on the system?  (ie auditing, profiling, general remote management, etc)

Comment 5 David Zeuthen 2010-09-01 13:49:33 UTC
(In reply to comment #4)
> > pkaction(1) is definitely not intended to be called from programs - it is
> > intended solely as an interactive sysadmin tool.
> 
> Ok.  That's kind of not the *nix programming model I'm familiar with, where
> command line tools (unless interactive in the ncurses way) generally get
> incorporated into scripting.  But, it's your util, not mine. ;)
> 
> Is there absolutely no scope for management utils or similar to use pkaction
> for querying actions on the system?  (ie auditing, profiling, general remote
> management, etc)

There probably is.. or will be. Btw, I think you are probably right that it's confusing that the man page is shown - as much as it's helpful, we should only show it on when requested via --help. I've filed https://bugs.freedesktop.org/show_bug.cgi?id=29936 for this. Will try to fix it soon.

Comment 6 Justin Clift 2010-09-13 10:16:47 UTC
Thanks.  Just discovered that a text mode install of RHEL 6 on a server doesn't include the "man" package either, so that'll probably help. :)

Comment 7 RHEL Product and Program Management 2011-01-07 16:04:44 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 14 Miloslav Trmač 2014-08-27 16:24:11 UTC
*** Bug 1130156 has been marked as a duplicate of this bug. ***

Comment 16 errata-xmlrpc 2014-10-14 07:27:30 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHBA-2014-1533.html


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