Editing /etc/exports shouldn't require root and/or manually entering password everytime

[purpleidea]

The NFS integration is a great feature, but between rebuilds my cached sudo password times out, and I have to re-enter it when doing an 'up' or even a 'destroy' because it modifies /etc/exports and related tasks via sudo.

I recommend that an /etc/sudoers.d/vagrant file be distributed with the package that allows people in a %vagrant group to not need a password for the relevant actions. If someone can suggest a different solution, I'd like to hear it too :)

If you accept this feature, I can perhaps write the patch, however it might require a few changes in plugins/hosts/linux/host.rb too. Other people who prefer to do this are welcome to!

Cheers,
James

[purpleidea]

PS: I should mention that besides editing /etc/exports there are a few other actions which require root. See plugins/hosts/linux/host.rb

[mitchellh]

This has been talked about time and time again. There are even some issues (don't know them off the top of my head but searching should bring them up) that have the proper sudoers contents.

I'm hoping to come up with a way to make it easier for users to not have to enter their password every time for this task but at the moment it isn't possible and I have no short term plans to make it so because there are workarounds. It is just marginally annoying.

[phinze]

I'm actually going to pass on this because I'm going to be extracting the "sudo helper" stuff from the VMware plugin I wrote and merging it into Vagrant core. This will allow you to specifically whitelist things like "vagrant-sudo-helper nfs-export" which is MUCH easier.

@mitchellh ^^ whatever happened to that idea? i'd be happy to help out if there's a clear-ish path, since i'm regularly one of the folks marginally annoyed by this 😉

[purpleidea]

FWIW here is my log file:

sudo: james : TTY=pts/2 ; PWD=/home/james/vagrant/gluster ; USER=root ; COMMAND=/bin/sed -r -e /^# VAGRANT-BEGIN:( 1000)? b67e0b49-0fac-4a05-ab2b-80f12ea73820/,/^# VAGRANT-END:( 1000)? b67e0b49-0fac-4a05-ab2b-80f12ea73820/ d -ibak /etc/exports
sudo: james : TTY=pts/2 ; PWD=/home/james/vagrant/gluster ; USER=root ; COMMAND=/bin/su root -c echo '# VAGRANT-BEGIN: 1000 b67e0b49-0fac-4a05-ab2b-80f12ea73820' >> /etc/exports
sudo: james : TTY=pts/2 ; PWD=/home/james/vagrant/gluster ; USER=root ; COMMAND=/bin/su root -c echo '/home/james/vagrant/gluster/.vagrant/machines/puppet/cache 192.168.142.19(rw,no_subtree_check,all_squash,anonuid=1000,anongid=1000,fsid=4058714981)' >> /etc/exports
sudo: james : TTY=pts/2 ; PWD=/home/james/vagrant/gluster ; USER=root ; COMMAND=/bin/su root -c echo '# VAGRANT-END: 1000 b67e0b49-0fac-4a05-ab2b-80f12ea73820' >> /etc/exports
sudo: james : TTY=pts/2 ; PWD=/home/james/vagrant/gluster ; USER=root ; COMMAND=/usr/sbin/exportfs -r

[purpleidea]

Why was this issue "closed" when it's real, and there were tentative offers of patches?

[mitchellh]

@phinze I started implementing it in a branch (actually, extracting the code from the VMware fusion plugin), but stopped to focus on other things. Its something I still want to solve, but I don't think my approach was correct. My approach was just... too big of a security risk.

@purpleidea I'm sorry, it was closed because I have no plans to fix this and I often feel like stale issues are worse than closed ones. As for patches: open a PR and it'll be a new issue and we can discuss there (and link back to this where it makes sense).

[purpleidea]

Okay, well, I added #2643 for now. Hopefully #2642 (this issue) will get reopened with a patch.