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. -- Best Regards, Leonid Chaichenets.
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
Hello Bazsi,
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:
actually I had exactly this problem (True Story (TM) :-p), -C validates its arguments only if syslog-ng was compiled with Linux-Caps: # syslog-ng --version syslog-ng 3.0.2 ... Enable-Linux-Caps: off ... # syslog-ng -C /tmp # pidof syslog-ng 19868 19866 One might think now, syslog-ng is chrooted in /tmp. Maybe its worth adding a waring if -C is used and Linux-Caps are not available.
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)
Thanks, thats great!
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
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.
I agree. Major linux distributions (Debian, SuSE, Ubuntu) do not ship 3.0.x yet, so the majority of users is probably still at 2.x. -- Best Regards, Leonid Chaichenets.
participants (2)
-
Balazs Scheidler
-
Leonid Chaichenets