[syslog-ng] Inconsistent Command Line Arguments

[Balazs Scheidler]

On Sat, 2009-06-20 at 18:41 +0200, Leonid Chaichenets wrote:
> Hello List,
> 
> there seems to be a problem with the command line parameter list of
> syslog-ng (tested for ver. 3.0.2): from what I understand from the
> source code command line parameters are defined in gprocess.c
> (g_process_option_entries[]) and in main.c (syslogng_options[]). Only
> the latter are described by syslog-ng --help (but both of them are
> usable).
> 
> Furthermore, the short version of '--chroot' should be '-C', according
> to the syslog-ng administration guide (The syslog-ng manual pages ->
> syslog-ng), but '-C' is defined in gprocess.c as "Set default
> capability set". According to gprocess.c the correct short version for
> '--chroot' would be '-R', but it collides and is overridden by the
> short version of the same name from main.c (there it means
> "persist-file").
> 
> IMHO this is a security relevant bug: one might think syslog-ng is
> running chrooted while it actually has root powers.
> 
> PS: This also applies to the git-versions syslog-ng-3.0.git and
> syslog-ng-3.1.git.
> 

You can get all arguments using --help-all, but there indeed seems to be
an unintended change in the short arguments. However I don't think the
problem is so serious as both the --chroot and --caps options validate
their arguments:

# syslog-ng -C /tmp
syslog-ng: Error parsing capabilities: /tmp

# syslog-ng -R /tmp
Error reading serialized data; error='Error reading file (short read)'

But you are right, this change is unfortunate and unintended. The reason
is that I've simply ported to an already existing codebase (gprocess) to
syslog-ng, without checking whether the command line arguments conflict.

The --help-all output properly lists command line arguments as it is
working right now. (e.g. -R is listed for --persist-file and --chroot
has no short option)

I have two options:

1) break the configurations of those users which already switched to 3.0
2) break the configurations of those users who are yet to upgrade to 3.0

Tough question.

I guess there are more users of the 2.x codebase than the ones that have
already upgraded, and these options is quite rarely used anyway. I think
I'll change the arguments back to their 2.0 equivalents and put a BIG
WARNING in the announcement text.

Any objections?



-- 
Bazsi