using sudo?, Re: [PATCH v2 8/8] test/py: efi_secboot: add test for intermediate certificates

[Tom Rini]

On Thu, Jul 09, 2020 at 02:33:49PM +0900, AKASHI Takahiro wrote:
> Tom,
> 
> On Wed, Jul 08, 2020 at 11:15:26PM -0400, Tom Rini wrote:
> > On Thu, Jul 09, 2020 at 09:58:03AM +0900, AKASHI Takahiro wrote:
> > 
> > > Hi Tom,
> > > 
> > > I'd like to make sure of your policy about usage of "sudo" on CI.
> > > Do you think that we should always avoid using "sudo" in testing?
> > > 
> > > I remember that you had allowed us to run sudo in (python)
> > > test scripts on Travis CI when I requested this (for FAT filesystem?).
> > 
> > So, the best practices at this time are to have the code try and use
> > guestmount (or similar tools) when possible and fall back to sudo, as
> > Ubuntu breaks guestmount (and similar tools) by default.
> 
> See the commands log (on my ubuntu 19.10) below:
> 
> ===8<===
> << try 1 >>
> tmp$ mkdir tmpdir
> tmp$ virt-make-fs -t vfat -s +1M --partition=gpt ./tmpdir tmp.img
> libguestfs: error: /usr/bin/supermin exited with error status 1.
> To see full error messages you may need to enable debugging.
> Do:
>   export LIBGUESTFS_DEBUG=1 LIBGUESTFS_TRACE=1
> and run the command again.  For further information, read:
>   http://libguestfs.org/guestfs-faq.1.html#debugging-libguestfs
> You can also run 'libguestfs-test-tool' and post the *complete* output
> into a bug report or message to the libguestfs mailing list.
> 
> << try 2 >>
> tmp$ LIBGUESTFS_DEBUG=1 virt-make-fs -t vfat -s +1M --partition=gpt ./tmpdir tmp.img
> ...
> supermin: kernel: kernel_version 5.3.0-62-generic
> supermin: kernel: modpath /lib/modules/5.3.0-62-generic
> cp: cannot open '/boot/vmlinuz-5.3.0-62-generic' for reading: Permission denied
> supermin: cp -p '/boot/vmlinuz-5.3.0-62-generic' '/var/tmp/.guestfs-1000/appliance.d.op62psoy/kernel': command failed, see earlier errors
> libguestfs: error: /usr/bin/supermin exited with error status 1, see debug messages above
> ...
> 
> << try 3 >>
> tmp$ sudo chmod a+rw /boot/vmlinuz-5.3.0-62-generic 
> tmp$ LIBGUESTFS_DEBUG=1 virt-make-fs -t vfat -s +1M --partition=gpt ./tmpdir tmp.img
> ...
> tmp$ ls -l tmp.img
> -rw-r--r-- 1 akashi akashi 1341440 Jul  9 13:50 tmp.img
> ===>8===
> 
> As you can see, virt-make-fs will fail on *standard* ubuntu.
> You have to change the permission of the current kernel's binary.

Yes, exactly.  This is an intentional behavior in Ubuntu (and not
Debian) and why we cannot rely on the various virt tools working.

I fixed the current tests over in
http://patchwork.ozlabs.org/project/uboot/patch/20200707155309.24770-1-trini@konsulko.com/
but need to follow up and try what Stephen was saying to clean it up
more still.

> While I can't make sure, we will have the same issue with guestmount
> as it will also create a minimum virtual machine before execution.
> 
> What does it mean?
> You must change the permission every time when you re-install the OS
> or re-bump the kernel version. Obviously, I can't do that from my own
> test script (without sudo).
> So if you don't have any way (or workaround) to deal with it,
> libguestfs-tools or guestmount cannot be a solution here.

Well, just like the test_fs tests, we try guestmount, if it doesn't work
we fall back to just sudo'ing what we need to run directly.  I think
Ubuntu did something very stupid here.  I just don't know if moving CI
to be Debian based (and I guess Travis is just working-around the issue
by default for us, given the fs tests run there today) is good enough as
it will leave everyone else's Ubuntu-based setups broken.

-- 
Tom
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 659 bytes
Desc: not available
URL: <https://lists.denx.de/pipermail/u-boot/attachments/20200709/ea823a5d/attachment.sig>