View Issue Details

IDProjectCategoryView StatusLast Update
0015552CentOS-7Cloud-Imagespublic2018-12-12 18:44
Reporterm01 Assigned To 
Status resolvedResolutionfixed 
Summary0015552: sudo config check fails in vagrant box due to /etc/sudoers.d/vagrant file having incorrect permissions
DescriptionWhen launching a frech Centos Vagrant box, the sudo config check (visudo -c) fails.

This means that automated provisioning tools that edit the sudo configuration fail, if they have some fail-safe built in to undo their changes in case the config fails to validate - e.g. puppet. My use-case involves using Vagrant for testing the puppet automated provisioning code.
Steps To ReproducePrep

$ cat Vagrantfile
Vagrant.configure("2") do |config|
  # this also happens with centos/7 = "centos-7-latest"
  config.vm.box_url = ""
$ vagrant up
Bringing machine 'default' up with 'virtualbox' provider...
==> default: Box 'centos-7-latest' could not be found. Attempting to find and install...
    default: Box Provider: virtualbox
    default: Box Version: >= 0
==> default: Box file was not detected as metadata. Adding it directly...
==> default: Adding box 'centos-7-latest' (v0) for provider: virtualbox
    default: Downloading:
==> default: Successfully added box 'centos-7-latest' (v0) for 'virtualbox'!
==> default: Importing base box 'centos-7-latest'...
==> default: Matching MAC address for NAT networking...
==> default: Setting the name of the VM: foo_default_1544224683514_41158
==> default: Clearing any previously set network interfaces...
==> default: Preparing network interfaces based on configuration...
    default: Adapter 1: nat
==> default: Forwarding ports...
    default: 22 (guest) => 2222 (host) (adapter 1)
==> default: Booting VM...
==> default: Waiting for machine to boot. This may take a few minutes...
    default: SSH address:
    default: SSH username: vagrant
    default: SSH auth method: private key
    default: Vagrant insecure key detected. Vagrant will automatically replace
    default: this with a newly generated keypair for better security.
    default: Inserting generated public key within guest...
    default: Removing insecure key from the guest if it's present...
    default: Key inserted! Disconnecting and reconnecting using new SSH key...
==> default: Machine booted and ready!
==> default: Checking for guest additions in VM...
    default: No guest additions were detected on the base box for this VM! Guest
    default: additions are required for forwarded ports, shared folders, host only
    default: networking, and more. If SSH fails on this machine, please install
    default: the guest additions and repackage the box to continue.
    default: This is not an error message; everything may continue to work properly,
    default: in which case you may ignore this message.
==> default: Rsyncing folder: /tmp/foo/ => /vagrant

Run visudo -c inside vagrant box.
Expected result: returns 0 and no error message
Actual result:
$ vagrant ssh
[vagrant@localhost ~]$ sudo visudo -c
/etc/sudoers: parsed OK
/etc/sudoers.d/vagrant: bad permissions, should be mode 0440

Additional Informationsudo itself works:
[vagrant@localhost ~]$ sudo echo hi

Permissions on sudoers file for vagrant user:
[vagrant@localhost ~]$ sudo ls -l /etc/sudoers.d/vagrant
-rw-r--r--. 1 root root 33 Dec 4 01:03 /etc/sudoers.d/vagrant

I didn't notice this problem with the archilinux/archlinux or bento/ubuntu-18.04 boxes. Here's the output from bento/ubuntu-18.04:
vagrant@vagrant:~$ sudo visudo -c
/etc/sudoers: parsed OK
/etc/sudoers.d/99_vagrant: parsed OK
/etc/sudoers.d/README: parsed OK
TagsNo tags attached.




2018-12-08 10:11

administrator   ~0033272

Reminder sent to: lpancescu



2018-12-09 18:36

developer   ~0033280

Thanks for the report!

We probably had this bug since at least 2015-05-12, the first commit on GitHub. Is it severe enough to warrant a 1811.02 release or can we wait until the next scheduled image release (1812)? I've already sent PR #142 on GitHub to fix this, needs to be merged by someone in the core team. The automatic test shows sporadic failures because sometimes my script wrongly thinks that the image build failed - I'll look into it.


2018-12-09 18:41

reporter   ~0033281

In my opinion this should be considered a blocker and a new image released as soon as possible.


2018-12-09 20:39

developer   ~0033284

I've built and tested the new images containing the bug fix this evening, will publish them after they are copied to and signed (probably 1-2 days' timeframe).


2018-12-12 18:43

developer   ~0033324

New images published as 1811.02 on Vagrant Cloud (formerly known as Atlas).


2018-12-12 18:44

developer   ~0033325

Permissions of /etc/sudoers.d/vagrant now explicitly set to 0440 in the kickstarts.

Issue History

Date Modified Username Field Change
2018-12-07 23:36 m01 New Issue
2018-12-08 10:11 arrfab Note Added: 0033272
2018-12-09 18:36 lpancescu Note Added: 0033280
2018-12-09 18:41 jrd Note Added: 0033281
2018-12-09 20:39 lpancescu Note Added: 0033284
2018-12-12 18:43 lpancescu Note Added: 0033324
2018-12-12 18:44 lpancescu Status new => resolved
2018-12-12 18:44 lpancescu Resolution open => fixed
2018-12-12 18:44 lpancescu Note Added: 0033325