Bug 1313709 - ipsec pluto returns zero even if it fails
ipsec pluto returns zero even if it fails
Status: CLOSED ERRATA
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: libreswan (Show other bugs)
6.9
All Linux
medium Severity medium
: rc
: 6.8
Assigned To: Paul Wouters
Jaroslav Aster
: Documentation
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2016-03-02 04:39 EST by Jaroslav Aster
Modified: 2017-03-21 05:05 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: No Doc Update
Doc Text:
undefined
Story Points: ---
Clone Of:
: 1313747 (view as bug list)
Environment:
Last Closed: 2017-03-21 05:05:57 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Jaroslav Aster 2016-03-02 04:39:41 EST
Description of problem:

ipsec pluto command returns zero even if it fails and prints nothing to the output.

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

libreswan-3.15-5.1.el6

How reproducible:

100%

Steps to Reproduce:

1. Install libreswan package and make sure, there is no db files in /etc.ipsec.d. It is true for fresh installation of libreswan, before service ipsec start command is run.

2. Run ipsec pluto command.

# yum install -y libreswan
...

# ls /etc/ipsec.d/
policies  v6neighbor-hole.conf

# ipsec pluto

# echo $?
0

# ps -fA|grep pluto
root     20056 17761  0 04:34 pts/0    00:00:00 grep pluto

# grep pluto /var/log/secure
Mar  2 04:33:38 unused-4-151 pluto[20028]: NSS DB directory: sql:/etc/ipsec.d
Mar  2 04:33:38 unused-4-151 pluto[20028]: NSS readonly initialization ("sql:/etc/ipsec.d") failed (err -8174) 
Mar  2 04:33:38 unused-4-151 pluto[20028]: FATAL: NSS initialization failure

Actual results:

ipsec returns zero and prints nothing to the output.

Expected results:

ipsec returns non-zero and prints something useful to the output.

Additional info:
Comment 1 Jaroslav Aster 2016-03-02 04:53:53 EST
It seems that openswan has a different behaviour than libreswan.

# rpm -q openswan
openswan-2.6.32-37.el6.x86_64

# killall pluto

# ps -fA|grep pluto
root     20479 20206  0 04:48 pts/0    00:00:00 grep pluto

# rm -f /etc/ipsec.d/*.db

# ls /etc/ipsec.d/
policies

# ipsec pluto

# echo $?
0

# ls /etc/ipsec.d/
cert8.db  key3.db  policies  secmod.db

# ps -fA|grep pluto
root     20501     1  0 04:48 ?        00:00:00 /usr/libexec/ipsec/pluto
root     20504 20501  0 04:48 ?        00:00:00 _pluto_adns
root     20507 20206  0 04:48 pts/0    00:00:00 grep pluto
Comment 2 Paul Wouters 2016-03-31 22:32:02 EDT
This is sort of not a bug. Whoever runs "ipsec pluto" manually outside of an init system should perform all the init system tasks. In systemd, that is the PreStart which runs "ipsec checknss" and in the sysvinit this is the init script.

The ipsec command is a shell script, and for its commands it runs:

exec "${path}" "$@"

so whatever it calls those failure codes are returned.

Testing a bit more, I notice that "ipsec pluto --nofork" works as expected
but "ipsec pluto" without --nofork does not.

I'll look at fixing that. But note that "ipsec pluto" should not be used by endusers :)
Comment 3 Paul Wouters 2016-04-28 11:09:17 EDT
I don't think we can fix this for the forked issue, as pluto forks correctly and the ipsec command returns successfully, and then in the background pluto dies. So I would like to suggest a CANTFIX resolution for this bug.
Comment 4 Jaroslav Aster 2016-04-28 11:35:37 EDT
Hi Paul,

thanks for the investigation. I understand that ipsec is only a shell around set of commands and it is difficult to fix it.

Would be possible to documented, somewhere, that ipsec's return code is not defined and the fact, ipsec returns zero, means nothing? Man-page would be good candidate :-).

I suggest not to close this bug, add flag Documentation and add some notes into the ipsec man-page.

What do you think?
Comment 5 Paul Wouters 2016-04-28 11:46:38 EDT
the ipsec command passes the return code for everything it calls fine. pluto is the only thing that can be called via the ipsec cmd that actually forks in the background.

The return codes _do_ matter :)

I've added the following to the upstream man page of ipsec:

RETURN CODE
       The ipsec command passes the return code of the sub-command back to the
       caller. The only exception is when ipsec pluto is used without
       --nofork, as it will fork into the background and the ipsec command
       returns success while the pluto daemon may in fact exit with an error
       code after the fork.


You can clone this bug for rhel7 if you want, and track it. It will come in via the next rebase in rhel 7.[34]
Comment 6 Jaroslav Aster 2016-04-28 11:59:56 EDT
Good enough for me. Thanks.
Comment 11 errata-xmlrpc 2017-03-21 05:05:57 EDT
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.

https://rhn.redhat.com/errata/RHBA-2017-0575.html

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