Comment 11 for bug 1220950

In response to Smoser's comment #10
> My issue with this is not hypervisor vendor nor hypervisor specific. The
> issue is that some party other than the user is going to attempt to
> execute code inside the instance, and that Ubuntu cannot know what that
> code is, nor control its behavior or release process. In order to be
> "cross distro", this code is quite likely to do things like check
> /etc/lsb_release or /etc/issue, and try to derive information from other
> files in /etc/ (/etc/udev.d, /etc/shadow ..). It also possibly does
> things that Ubuntu would not certify as "supported". Perhaps it enables
> additional repositories or loads additional kernel modules.

Have you read the code? Rather than beating up some academic concern, which may or may not have any basis in fact, it would be more constructive to identify specific areas of concern. Saying that it "possibly does things that Ubuntu would certify" with out supporting it is to make an unwarranted accusation.

> There is no sane way in which Ubuntu could hope to keep our code working
> across releases or even within an SRU. Any change Ubuntu makes can
> potentially break this code.

Are you actually implying that we should not include things in main which might get broken between releases? Looking over the bug this,

This is a Red Herring. Changes to the base of Ubuntu happen with each releases, and with each release things are broken and fixed. Open-vm-tools has been around since Lucid in Ubuntu, and the package was first created in 2007. If the criteria to exclude something from main is because it might break with a future upgrade, then nothing should be included in main -- including Cloud-init and other packages.

Essentially you are arguing the "who's going to maintain this code," question. And the answer here is that upstream source pro-actively considers the needs of Ubuntu. Ubuntu is treated as a first-class citizen in the VMWare world.

> There is essentially no difference here between *user* written code that
> does that and hypervisor-vendor written code, other than who can fix the
> code. If the change comes from the hypervisor, then the user quite
> possibly has no way to fix, and Ubuntu quite possibly has no way to fix.
> This leaves the user and ubuntu dependent on the hypervisor to never break
> anything.
If I am understanding the code properly, the auto-upgrade functionality is _not_ implemented in the open-vm-tools. The only reference to the ability to upgrade is in lib/include/vmware/guestrpc/tclodefs.h, where a constant is defined. However, I can find no code that actually handles that upgrade. This would mean that there is a difference between the proprietary tools and the open-vm-tools. It also means that this concern is moot. Please feel free to examine the code and prove me wrong on this point.

However, there is an ability to run scripts on the machine. This functionality is exposed services/plugins/vix/vixTools.c. What this allows is for an authenticated user to run an arbitrary script. I would note that there are many tools that allow a user to run arbitrary scripts, with SSH being perhaps the most famous. Just because the trigger for running the arbitrary script comes from the hypervisor does not mean that the mechanism is unsupportable. The trigger has to come from the user via the hypervisor.

But let's assume that the code is hypervisor written and that the hypervisor delivers the code via the arbitrary script execution. By accepting the package into main, we are supporting the channel, not the what is delivered via the channel. It is nonsensical to argue that Ubuntu has to support how that channel is used, otherwise SSH and a myriad of other tools are unsupportable. If the hypervisor delivers a bad payload over that channel, then it is a bug in the hypervisor, not Ubuntu or the package that enabled that channel. Essentially you are conflating the channel with a potential result. From Ubuntu's perspective, a hypervisor payload that breaks the guest is an issue with the hypervisor and should be treated as an externality not unlike a BIOS or UEFI update. If the hypervisor does something bad or uses a channel to break something, the ownership of that problem is clearly on the hypervisor not on Ubuntu.

So in the spirit of the dialog, if I understand smoser's objections, since there is no auto-upgrade of the tools implemented, then the remaining concerns are moot?