cloud-init

unittest failure when running tests as root: no such file or dir: 'ud'

Bug #1856096 reported by Joshua Powers
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
cloud-init
Fix Released
High
Joshua Powers

Bug Description

When building master on LXD or running tox on a fresh Bionic LXD the following test failures show up:

https://paste.ubuntu.com/p/5p8cfjFN8D/

This is not reproduced on a VM or baremetal.

This is slightly confusing as the load_file function has not be touched since in multiple years, nor as the query cmd. Is this related to the SRU lxd issues?

Steps to reproduce
---
lxc launch ubuntu-daily:b b
lxc exec b bash
git clone https://github.com/canonical/cloud-init
cd cloud-init
sudo apt update -qq
sudo apt install tox -y
tox

Joshua Powers (powersj)
summary: - test escape on LXD: no such file or dir: 'ud'
+ unittest failure on LXD: no such file or dir: 'ud'
Revision history for this message
Paride Legovini (paride) wrote : Re: unittest failure on LXD: no such file or dir: 'ud'

Apparently the trigger is not LXD but the fact that tox runs as root. It can reproduce it on bare metal.

summary: - unittest failure on LXD: no such file or dir: 'ud'
+ unittest failure when running tests as root: no such file or dir: 'ud'
Yhaza (mhenyhazz177999000)
information type: Public → Public Security
information type: Public Security → Public
Revision history for this message
Joshua Powers (powersj) wrote :

# WORKS
$ ./.tox/py3/bin/nosetests cloudinit.cmd.tests.test_query:TestQuery.test_handle_args_dumps_all_instance_data

# FAILS
$ sudo ./.tox/py3/bin/nosetests cloudinit.cmd.tests.test_query:TestQuery.test_handle_args_dumps_all_instance_data

Revision history for this message
Joshua Powers (powersj) wrote :

The difference is in cloudinit/cmd/query.py:

    if uid != 0:
        instance_data['userdata'] = (
            '<%s> file:%s' % (REDACT_SENSITIVE_VALUE, user_data_fn))
        instance_data['vendordata'] = (
            '<%s> file:%s' % (REDACT_SENSITIVE_VALUE, vendor_data_fn))
    else:
        instance_data['userdata'] = util.load_file(user_data_fn)
        instance_data['vendordata'] = util.load_file(vendor_data_fn)

Effectively, as root it tries to really load the fake user and vendor data files.

Revision history for this message
Joshua Powers (powersj) wrote :

Wrapping each call to query with the following should fix this:

with mock.patch('os.getuid') as m_getuid:
    m_getuid.return_value = 100

Revision history for this message
Joshua Powers (powersj) wrote :

https://github.com/canonical/cloud-init/pull/113

Changed in cloud-init:
status: New → In Progress
assignee: nobody → Joshua Powers (powersj)
importance: Undecided → High
Chad Smith (chad.smith)
Changed in cloud-init:
status: In Progress → Fix Committed
Revision history for this message
Chad Smith (chad.smith) wrote : Fixed in cloud-init version 19.4.

This bug is believed to be fixed in cloud-init in version 19.4. If this is still a problem for you, please make a comment and set the state back to New

Thank you.

Changed in cloud-init:
status: Fix Committed → Fix Released
Revision history for this message
James Falcon (falcojr) wrote :

Tracked in Github Issues as https://github.com/canonical/cloud-init/issues/3517

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.
Subscribing...

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.