[RFC] Every executable filename starting with zypper is considered a subcommand

[fabiomux]

In previous versions were considered valid subcommands only those files under the folder /usr/lib/zypper/commands/.

In zypper v.1.14.42 (I don't know exactly when this started) all the filename executables like zypper-... are considered valid subcommand.

How to reproduce it:

$ touch ~/bin/zypper-unwantedsubc
$ chmoud u+x ~/bin/zypper-unwantedsubc
$ zypper help

As you can see also my other plugins, having a counterpart outside the aforementioned folder, are involved in this bug, while previously everything worked fine.

[mlandres]

@fabiomux AFAICS not much was changed and also the man page states that this is the intended beavior. The only change recently was, that help and help subcommand now list all subcommands zypper sees.

[fabiomux]

@mlandres thank you to point me in the right direction, so I wrongly assumed, looking at a plugin took as an example, that the only valid folder was /usr/lib/zypper/commands, and the zypper help subcommand section, hiding that till the latest releases didn't... help me.

Well, my question now is, whether or not shouldn't be better to consider a valid path only the zypper/commands subfolder, I mean, shouldn't be safer to limit the path?

[mlandres]

Well, there are people appreciating to be able to write their own extensions easily and to have them hooked into zyppers help overview and TAB-expansion. There are also packages out which install their subcommands in the PATH. It's similar to the way e.g. git collects it's custom commands.

We do not allow to shadow zypper builtin commands, so zyppers behavior can not be amended this way.

[fabiomux]

Well, there are people appreciating to be able to write their own extensions easily and to have them hooked into zyppers help overview and TAB-expansion.

And I am among them, I published one and going to publish a second maybe :)

It's similar to the way e.g. git collects it's custom commands.

But while git works in simple userspace, zypper, being a system command, works as a privileged user sometimes.

We do not allow to shadow zypper built-in commands, so zyppers behavior can not be amended this way.

Noticed that, but some zypper-arr or similar can always be built to cheat...

[mlandres]

Frankly, if someone is able to package and ship a cheating zypper-arr to your system, he's able to arrange almost anything at install time of the package.

If you actually feel uncomfortable with the behavior, we could spend a zypper.conf option to restrict subcommands to /usr/lib/zypper/commands, but a cheating package will be able to install its stuff there as well.

[fabiomux]

Frankly, if someone is able to package and ship a cheating zypper-arr to your system, he's able to arrange almost anything at install time of the package.

That's the point, if for package you mean an RPM package installed by an admin you are absolutely alright, and that's why I would like a restricted path, at least I am sure that a possible threat leveraging on zypper plugins comes only from one direction (the zypper subfolder with restricted access), and plus only an admin can put it there.

When zypper considers a valid plugin also a script under my $HOME/bin, or any other $HOME subfolder added to the PATH, and contains some evil code waiting only to be run as a privileged user... here comes my concern. Maybe I am just overthinking, but evil minds never take a nap, unfortunately.

If you actually feel uncomfortable with the behavior, we could spend a zypper.conf option to restrict subcommands to /usr/lib/zypper/commands,

Yes, that would be great, thank you!

but a cheating package will be able to install its stuff there as well.

Absolutely alright! And plus, once installed an evil package doesn't need to leverage on zypper plugins to be harmful and achieve a more sophisticated attack, but this would be already the worst case. What I want is to reduce the risk to have unwanted sneaky scripts that might be run in super user mode.

[mlandres]

For zypper-1.14.50