(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.

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.

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.

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)

(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.

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. :)

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.

*** Bug 1130156 has been marked as a duplicate of this bug. ***

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