In my recipe, I am trying to set up a user rsnapshot to be permitted to run rsync with passwordless sudo. I would expect that's what the snippet below should do. However, it fails with a validation error. If I remove the commands line, all works fine.

sudo "<redacted>" do
  user "rsnapshot"
  nopasswd true
  commands ['rsync']
end

When this recipe gets run on a host, I get this error.

    ================================================================================
    Error executing action `install` on resource 'sudo[<redacted>]'
    ================================================================================

    SystemExit
    ----------
    exit

    Cookbook Trace:
    ---------------
    /var/chef/cache/cookbooks/sudo/providers/default.rb:51:in `validate_fragment!'
    /var/chef/cache/cookbooks/sudo/providers/default.rb:100:in `render_sudoer'
    /var/chef/cache/cookbooks/sudo/providers/default.rb:117:in `block in class_from_file'

    Resource Declaration:
    ---------------------
    # In /var/chef/cache/cookbooks/<redacted>/recipes/default.rb

     19: sudo "<redacted>" do
     20:   user "rsnapshot"
     21:   nopasswd true
     22:   commands ['rsync']
     23: end
     24:

    Compiled Resource:
    ------------------
    # Declared in /var/chef/cache/cookbooks/<redacted>/recipes/default.rb:19:in `from_file'

    sudo("<redacted>") do
      action :install
      supports {:report=>true, :exception=>true}
      retries 0
      retry_delay 2
      default_guard_interpreter :default
      declared_type :sudo
      cookbook_name "<redacted>"
      recipe_name "default"
      user "rsnapshot"
      nopasswd true
      commands ["rsync"]
      host "ALL"
      runas "ALL"
    end

Cookbook version

3.5.3

Chef-client version

13.7.16

Platform Details

enterprise linux 7

Scenario:

https://github.com/chef-cookbooks/sudo/blob/master/providers/default.rb#L80 ignores group setting if user is set.

sudo 'app_admins'  do
  user    'bob,dave'
  group 'web_admins,%db_admins'  # strings with a % between to fake out same Line80
  commands  ['/sbin/service httpd restart']
end

-> /etc/sudoers.d/app_admins

bob,dave ALL(ALL)=ALL /sbin/service httpd restart

Steps to Reproduce:

as in scenario

Expected Result:

bob,dave,%web_admins,%db_admins ALL(ALL)=ALL /sbin/service httpd restart

(with groups and users shown)

Actual Result:

as in scenario - groups ignored on L80

It doesn't appear to accept

user        [*v['user']].reject{|i| i==''} + [*v['group']].reject{|i| i==''}.map{|f| "%#{f}"}

either -- it'll blow chunks when user=[] or '' . My ability to fake this cookbook out is ever more impaired!

Can we consider swapping L80 with something like

sudoer = ([*new_resource.user] + [*new_resource.group].map{|grp| "%#{grp}"}).join(',')

? Will that work to get us the bare 'string xor string' logic, while still providing for users and groups in any number as string or array-of-string ?

Hi,

I am trying to run this on debian 11;

This is what I am geting:
Recipe Compile Error in /root/chef-solo/cookbooks/sudo/attributes/default._ORIGINAL

Chef::Exceptions::AttributeNotFound

could not find filename for attribute default._ORIGINAL in cookbook sudo

System Info:

chef_version=14.4.56
platform=debian
platform_version=11.5
ruby=ruby 2.5.1p57 (2018-03-29 revision 63029) [x86_64-linux]
program_name=/usr/bin/chef-client
executable=/opt/chef/bin/chef-client

Running handlers:
[2022-11-02T07:38:21+00:00] ERROR: Running exception handlers
[2022-11-02T07:38:21+00:00] ERROR: Running exception handlers
Running handlers complete
[2022-11-02T07:38:21+00:00] ERROR: Exception handlers complete
[2022-11-02T07:38:21+00:00] ERROR: Exception handlers complete
Chef Client failed. 0 resources updated in 08 seconds
[2022-11-02T07:38:21+00:00] FATAL: Stacktrace dumped to /root/chef-solo/chef-stacktrace.out
[2022-11-02T07:38:21+00:00] FATAL: Stacktrace dumped to /root/chef-solo/chef-stacktrace.out
[2022-11-02T07:38:21+00:00] FATAL: Please provide the contents of the stacktrace.out file if you file a bug report
[2022-11-02T07:38:21+00:00] FATAL: Please provide the contents of the stacktrace.out file if you file a bug report
[2022-11-02T07:38:21+00:00] FATAL: Chef::Exceptions::AttributeNotFound: could not find filename for attribute default._ORIGINAL in cookbook sudo
[2022-11-02T07:38:21+00:00] FATAL: Chef::Exceptions::AttributeNotFound: could not find filename for attribute default._ORIGINAL in cookbook sudo

This is content of default file>

Cookbook Name:: sudo

Attribute File:: default

Copyright 2008-2013, Opscode, Inc.

Licensed under the Apache License, Version 2.0 (the "License");

you may not use this file except in compliance with the License.

You may obtain a copy of the License at

http://www.apache.org/licenses/LICENSE-2.0

Unless required by applicable law or agreed to in writing, software

distributed under the License is distributed on an "AS IS" BASIS,

WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.

See the License for the specific language governing permissions and

limitations under the License.

default['authorization']['sudo']['groups'] = ['sysadmin']
default['authorization']['sudo']['users'] = []
default['authorization']['sudo']['passwordless'] = false
default['authorization']['sudo']['include_sudoers_d'] = false
default['authorization']['sudo']['agent_forwarding'] = false
#default['authorization']['sudo']['sudoers_defaults'] = ['!lecture,tty_tickets,!fqdn']
default['authorization']['sudo']['sudoers_defaults'] = ['env_reset']
default['authorization']['sudo']['command_aliases'] = []

case node['platform_family']
when 'smartos'
default['authorization']['sudo']['prefix'] = '/opt/local/etc'
when 'freebsd'
default['authorization']['sudo']['prefix'] = '/usr/local/etc'
else
default['authorization']['sudo']['prefix'] = '/etc'
end

Cookbook version

5.3.1

Chef-client version

chef-12.18.31-1.

Platform Details

CetnOS 6/7

Scenario:

If a refreshly installed server doesn't have the sudo package installed (this happened when using only @core packages), the cookbook does not install the package.

Steps to Reproduce:

Install a fresh CentOS server wth on @core group packages

Expected Result:

The sudo package to be installed

As far as I can see there was a changed that setup sudo only on docker I was wondering what are you only handling this cases?

Cookbook version

3.5.3

Chef-client version

13.9.1

Platform Details

Vagrant boxes:
bento/centos-6.9
bento/centos-7.4
oel66

Scenario:

On second kitchen converge in row following recipe fails:

           sudo("users_cloud_admin") do
             action [:install]
             default_guard_interpreter :default
             declared_type :sudo
             cookbook_name "hc_base_user"
             recipe_name "linux"
             user "+users_cloud_admin"
           end

Steps to Reproduce:

Just declare:

  sudo netgroup do
    user "+#{netgroup}"
  end

Expected Result:

sudo entry created for netgroup and successful converge

Actual Result:

Exception thrown. Converger interrupted.

       Recipe: hc_base_user::linux
         * sudo[users_cloud_admin] action install

           ================================================================================
           Error executing action `install` on resource 'sudo[users_cloud_admin]'
           ================================================================================

           Errno::ENOENT
           -------------
           No such file or directory - visudo

           Cookbook Trace:
           ---------------
           /tmp/kitchen/cache/cookbooks/sudo/providers/default.rb:49:in `validate_fragment!'
           /tmp/kitchen/cache/cookbooks/sudo/providers/default.rb:104:in `render_sudoer'
           /tmp/kitchen/cache/cookbooks/sudo/providers/default.rb:126:in `block in class_from_file'

           Resource Declaration:
           ---------------------
           # In /tmp/kitchen/cache/cookbooks/hc_base_user/recipes/linux.rb

            75:   sudo netgroup do
            76:     user "+#{netgroup}"
            77:   end
            78: end

           Compiled Resource:
           ------------------
           # Declared in /tmp/kitchen/cache/cookbooks/hc_base_user/recipes/linux.rb:75:in `block in from_file'

           sudo("users_cloud_admin") do
             action [:install]
             default_guard_interpreter :default
             declared_type :sudo
             cookbook_name "hc_base_user"
             recipe_name "linux"
             user "+users_cloud_admin"
           end

           System Info:
           ------------
           chef_version=13.9.1
           platform=oracle
           platform_version=6.6
           ruby=ruby 2.4.3p205 (2017-12-14 revision 61247) [x86_64-linux]
           program_name=chef-client worker: ppid=6016;start=18:30:28;
           executable=/opt/chef/bin/chef-client

STACK TRACE:

Errno::ENOENT: sudo[users_cloud_admin] (hc_base_user::linux line 75) had an error: Errno::ENOENT: No such file or directory - visudo
/opt/chef/embedded/lib/ruby/gems/2.4.0/gems/mixlib-shellout-2.3.2/lib/mixlib/shellout/unix.rb:340:in `exec'
/opt/chef/embedded/lib/ruby/gems/2.4.0/gems/mixlib-shellout-2.3.2/lib/mixlib/shellout/unix.rb:340:in `block in fork_subprocess'
/opt/chef/embedded/lib/ruby/gems/2.4.0/gems/mixlib-shellout-2.3.2/lib/mixlib/shellout/unix.rb:318:in `fork'
/opt/chef/embedded/lib/ruby/gems/2.4.0/gems/mixlib-shellout-2.3.2/lib/mixlib/shellout/unix.rb:318:in `fork_subprocess'
/opt/chef/embedded/lib/ruby/gems/2.4.0/gems/mixlib-shellout-2.3.2/lib/mixlib/shellout/unix.rb:95:in `run_command'
/opt/chef/embedded/lib/ruby/gems/2.4.0/gems/mixlib-shellout-2.3.2/lib/mixlib/shellout.rb:263:in `run_command'
/tmp/kitchen/cache/cookbooks/sudo/providers/default.rb:49:in `validate_fragment!'
/tmp/kitchen/cache/cookbooks/sudo/providers/default.rb:104:in `render_sudoer'
/tmp/kitchen/cache/cookbooks/sudo/providers/default.rb:126:in `block in class_from_file'
(eval):2:in `block in action_install'
/opt/chef/embedded/lib/ruby/gems/2.4.0/gems/chef-13.9.1/lib/chef/provider.rb:225:in `instance_eval'
/opt/chef/embedded/lib/ruby/gems/2.4.0/gems/chef-13.9.1/lib/chef/provider.rb:225:in `compile_and_converge_action'
(eval):2:in `action_install'
/opt/chef/embedded/lib/ruby/gems/2.4.0/gems/chef-13.9.1/lib/chef/provider.rb:171:in `run_action'
/opt/chef/embedded/lib/ruby/gems/2.4.0/gems/chef-13.9.1/lib/chef/resource.rb:592:in `run_action'
/opt/chef/embedded/lib/ruby/gems/2.4.0/gems/chef-13.9.1/lib/chef/runner.rb:70:in `run_action'
/opt/chef/embedded/lib/ruby/gems/2.4.0/gems/chef-13.9.1/lib/chef/runner.rb:98:in `block (2 levels) in converge'
/opt/chef/embedded/lib/ruby/gems/2.4.0/gems/chef-13.9.1/lib/chef/runner.rb:98:in `each'
/opt/chef/embedded/lib/ruby/gems/2.4.0/gems/chef-13.9.1/lib/chef/runner.rb:98:in `block in converge'
/opt/chef/embedded/lib/ruby/gems/2.4.0/gems/chef-13.9.1/lib/chef/resource_collection/resource_list.rb:94:in `block in execute_each_resource'
/opt/chef/embedded/lib/ruby/gems/2.4.0/gems/chef-13.9.1/lib/chef/resource_collection/stepable_iterator.rb:114:in `call_iterator_block'

Actually visudo is installed in /usr/sbin/visudo. However during second converge /usr/sbin is not found by chef (!). Despite 'sudo bash' showing correct path. It's something to do with 'secure_path' setting which disappears from newly generated sudoers. As w workaround I'm explicitly adding secure_path = /sbin:/bin:/usr/sbin:/usr/bin as sudoers_defaults attribute. But this is not very clean, is it? Cookbooks chops off the branch it is sitting on...

Cookbook version

5.4.4

Chef-client version

chef_version=12.21.26

Platform Details

platform=centos
platform_version=7.7.1908
ruby=ruby 2.3.5p376 (2017-09-14 revision 59905) [x86_64-linux]

Scenario:

I am using chef 12, where "sudo" resource is not available. I used this cookbook to achieve the same but failed due to syntax issue in metadata.rb

Steps to Reproduce:

1. Created a cookbook sudo.
2. Clone the repo to the sudo cookbook.
3. Run using chef-client

Result:

Not sure this issue is due to my chef version, but I am getting the following error while running.
resolving cookbooks for run list: ["sudo"]
Error Resolving Cookbooks for Run List:

Unexpected Error:
SyntaxError: /root/cookbooks/sudo/metadata.rb:6: syntax error, unexpected tIDENTIFIER, expecting end-of-input
version '5.4.4'
^

System Info:
chef_version=12.21.26
platform=centos
platform_version=7.7.1908
ruby=ruby 2.3.5p376 [x86_64-linux]

Solution

I found that the line 6 in metadata.rb is caused the issue
description 'Installs sudo and configures /etc/sudoers'\

The unwanted delimiter \ at the end of the line caused the issue.

Will create a PR after removing the same.

2.7.1 was released 6 months ago, but master shows the same version in the metadata. What is required to cut a 2.8 release with this change 215145c, from August?

Can the metadata in master be bumped to a new version after release?

my code:
sudo 'patchusr' do
user 'patchusr'
commands ['yum check-update', 'yum update']
nopasswd true
end

System Info:
------------
chef_version=16.1.16
platform=redhat
platform_version=6.10
ruby=ruby 2.7.1p83 (2020-03-31 revision a0c7c23c9c) [x86_64-linux]
program_name=/usr/bin/chef-client
executable=/opt/chef/bin/chef-client

cookbook version:

• sudo (5.4.4)

Chef::Exceptions::ValidationFailed
Proposed content for /etc/sudoers.d/patchusr failed verification cat /etc/sudoers | /usr/sbin/visudo -cf - && /usr/sbin/visudo -cf %{path}
STDOUT: parse error in stdin near line 156

There are cases where someone may not want to add a user setting, but only a env_keep.

Example for rbenv:

Defaults env_keep += "PATH RBENV_ROOT RBENV_VERSION"

I'd assume the lwrp would be able to handle something like:

sudo 'rbenv' do
  env_keep_add [ 'PATH', 'RBENV_ROOT', 'RBENV_VERSION' ]
end

but this fails fragment validation as it still adds irrelevant user information:

% ALL=(ALL) ALL

From the manpage: http://linux.die.net/man/5/sudoers

sudo will read each file in /etc/sudoers.d, skipping file names that end in '~' or contain a '.' character to avoid causing problems with package manager or editor temporary/backup files.

https://github.com/chef-cookbooks/sudo/blob/master/providers/default.rb#L80

Should be something like:

def filter_characters(string)
  string.gsub(/[\.\~]/, '')
end

resource = template "#{node['authorization']['sudo']['prefix']}/sudoers.d/#{filter_characters(new_resource.name)}" do

Cookbook version

3.4.0

Chef-client version

Chef 11.10

Platform Details

Amazon Linux

Scenario:

Bootstrap fails as 'file' referenced by 'cookbook_file' resource has moved out of default directory

Steps to Reproduce:

Include default recipe

Expected Result:

Failing with error Cookbook 'sudo' (3.4.0) does not contain a file at any of these locations:

Actual Result:

Converge failing.

Cookbook version

3.5.3

Chef-client version

13.7.16

Platform Details

enterprise linux 7

Scenario:

https://github.com/chef-cookbooks/sudo/blob/master/providers/default.rb#L84 doesn't proper prepend group-marker to group list in string.

sudo 'app_admins'  do
  group 'web_admins,db_admins'
  commands  ['/sbin/service httpd restart']
end

-> /etc/sudoers.d/app_admins

%web_admins,db_admins ALL(ALL)=ALL /sbin/service httpd restart

Steps to Reproduce:

as in scenario

Expected Result:

%web_admins,%db_admins ALL(ALL)=ALL /sbin/service httpd restart

(with the % prepended on the second group)

Actual Result:

as in scenario - one leading % only

Hmm. It doesn't accept group=>['group1','group2'] right?

Cookbook version

3.1.0

Chef-client version

12.13.37

Platform Details

Ubuntu 14.04

Scenario:

I've for some time been using the sudo resource to configure additional users, without running the sudo::default recipe to manage the actual /etc/sudoers file (this is just using ubuntu defaults).

On upgrading past version 2.10 today I noticed a worrying warning appearing in my provisioning logs : WARN: andrew will be rendered, but will not take effect because node['authorization']['sudo']['include_sudoers_d'] is set to false!. This warning was introduced in #82

However, it seemed like everything was working as usual post-provisioning. After some digging, I realised that as I'm not using sudo::default, my /etc/sudoers file isn't being overwritten, and by default ubuntu includes the sudoers.d - so actually the warning is incorrect, my sudo resource should (and does) take effect.

Steps to Reproduce:

Provision on ubuntu with a basic recipe that just defines a sudo resource but never runs sudo::default.

Expected Result:

Everything works as before, no warnings.

Actual Result:

Everything works, but the log output gives a spurious warning that my sudo permissions are about to disappear.

Cookbook version

latest v5.3.3

Chef-client version

Chef: 13.8.5

Platform Details

VirtualBox Ubuntu 16.04.4

Scenario:

I am following https://blog.chef.io/2014/07/10/managing-users-and-ssh-keys-in-a-hybrid-world/ and at the step of adding ;

node.default['authorization']['sudo']['passwordless'] = true
 include_recipe "sudo"

to default recipe, when I execute chef-client /etc/sudoers.d/ doesn't update with a sysadmin or specific user.

Steps to Reproduce:

follow: https://blog.chef.io/2014/07/10/managing-users-and-ssh-keys-in-a-hybrid-world/

Expected Result:

I should be creating multiple sudoers that have passwordless access

Actual Result:

No new users or groups are created.

The 5.4.7 release that marks this as deprecated includes a bunch of Mac's infamous ._ files.
This appears to cause Policyfile validation errors, at least if the Policy lock file was created on a Mac, and then validated on Linux.

I see errors like this on Linux:
Reason: (ChefDK::CachedCookbookModified) Cached cookbook 'sudo' (5.4.7) has been modified since the lockfile was generated. Cached cookbooks cannot be modified.

Downloading the cookbook from Supermarket directly shows the extra files that weren't present in 5.4.6

$ curl -L -O https://supermarket.chef.io:443/api/v1/cookbooks/sudo/versions/5.4.7/download
  % Total    % Received % Xferd  Average Speed   Time    Time     Time  Current
                                 Dload  Upload   Total   Spent    Left  Speed
100   180  100   180    0     0    316      0 --:--:-- --:--:-- --:--:--   316
100 17075  100 17075    0     0  25026      0 --:--:-- --:--:-- --:--:--     0


$ tar -zxvf download
sudo/
sudo/._LICENSE
sudo/LICENSE
sudo/._CHANGELOG.md
sudo/CHANGELOG.md
sudo/resources/
sudo/metadata.json
sudo/._README.md
sudo/README.md
sudo/attributes/
sudo/recipes/
sudo/files/
sudo/templates/
sudo/metadata.rb
sudo/chefignore
sudo/._kitchen.dokken.yml
sudo/kitchen.dokken.yml
sudo/templates/default/
sudo/templates/mac_os_x/
sudo/templates/mac_os_x/._sudoers.erb
sudo/templates/mac_os_x/sudoers.erb
sudo/templates/default/._sudoer.erb
sudo/templates/default/sudoer.erb
sudo/templates/default/._sudoers.erb
sudo/templates/default/sudoers.erb
sudo/files/._README
sudo/files/README
sudo/recipes/._default.rb
sudo/recipes/default.rb
sudo/attributes/._default.rb
sudo/attributes/default.rb
sudo/resources/default.rb

Cookbook version

[Version of the cookbook where you are encountering the issue]
2.11.0

Chef-client version

[Version of chef-client in your environment]
Chef: 12.8.1

Platform Details

[Operating system distribution and release version. Cloud provider if running in the cloud]
Red Hat Enterprise Linux Server release 7.2 (Maipo)

Scenario:

[What you are trying to achieve and you can't?]
Just want keep the original sudoer file as much as possible.

Steps to Reproduce:

[If you are filing an issue what are the things we need to do in order to repro your problem? How are you using this cookbook or any resources it includes?]

attribute/default.rb

RHEL family 7.x sudoer default

default['authorization']['sudo']['sudoers_defaults'] = [
'requiretty',
'!visiblepw',
'env_reset',
'env_keep = "COLORS DISPLAY HOSTNAME HISTSIZE INPUTRC KDEDIR LS_COLORS"',
'env_keep += "MAIL PS1 PS2 QTDIR USERNAME LANG LC_ADDRESS LC_CTYPE"',
'env_keep += "LC_COLLATE LC_IDENTIFICATION LC_MEASUREMENT LC_MESSAGES"',
'env_keep += "LC_MONETARY LC_NAME LC_NUMERIC LC_PAPER LC_TELEPHONE"',
'env_keep += "LC_TIME LC_ALL LANGUAGE LINGUAS _XKB_CHARSET XAUTHORITY"',
'always_set_home',
'secure_path = /sbin:/bin:/usr/sbin:/usr/bin'
]

Expected Result:

[What are you expecting to happen as the consequence of above reproduction steps?]

The original parameters in the sudoers file is preserved and only modified to add any new parameter.

Actual Result:

[What actually happens after the reproduction steps? Include the error output or a link to a gist if possible.]

The sudoers file is completely overwritten by default['authorization']['sudo']['sudoers_defaults'] even if you do not provide any.

I think it is separate from #103. I am just not sure if it should be fixed here or in chef-client cookbook.

visudo is called directly. In my case it is not in the PATH (defaults for this AMI). Can we safely assume it is always /usr/sbin/visudo?

Cookbook version

3.5.3

Chef-client version

13.4.24

Platform Details

Distributor ID: Ubuntu
Description:    Ubuntu 16.04.3 LTS
Release:        16.04
Codename:       xenial

AWS AMI - ubuntu/images/hvm-ssd/ubuntu-xenial-16.04-amd64-server-20170811 (ami-674cbc1e)

Scenario:

Trying to run sudo resource using chef running from cron.

Steps to Reproduce:

node.default["authorization"]["sudo"]["groups"] = %w(sudo admin)
node.default["authorization"]["sudo"]["include_sudoers_d"] = true
node.default["authorization"]["sudo"]["passwordless"] = true
node.default["authorization"]["sudo"]["sudoers_defaults"] = [
  "env_reset",
  "mail_badpass",
  'secure_path="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin"',
  "syslog_goodpri=debug"
]

include_recipe "sudo"

sudo "foo" do
  commands ["/usr/local/sbin/foo.sh"]
  nopasswd true
  user     "%aux"
end

Expected Result:

Chef runs fine.

Actual Result:

[2017-09-19T10:12:40+00:00] WARN: Error during compile phase, no Datadog metrics available.
[2017-09-19T10:12:41+00:00] ERROR: Exception handlers complete
[2017-09-19T10:12:41+00:00] FATAL: Stacktrace dumped to /var/chef/cache/chef-stacktrace.out
[2017-09-19T10:12:41+00:00] FATAL: Please provide the contents of the stacktrace.out file if you file a bug report
...
Errno::ENOENT: No such file or directory - visudo
...

Please set default['authorization']['sudo']['groups'] = [] instead of = ['sysadmin']. The 'users' cookbook has, of course, deprecated the default 'sysadmin' recipe and group, and this cookbook should follow suit.

Thanks!

get clone

If include_sudoers_d is set to false (which is default) , sudo LWRP will have no effect. This is documented, but given both attribute and lwrp is offered by the same cookbook, it will be nice to get warning message sudo lwrp is being used, but include_sudoers_d is set to false.

There's no current way for a chef deployment to clear erroneous and out of date /etc/suders.d entries. Since sudo entries are order sensitive, non-chef entries parsed early can affect behavior of later entries added by chef, it can actually break chef based sudo deployments if /etc/suders is enabled.

I suggest adding a "clear_sudoers_d" recipe specifically for such cleanup operations, and will be happy to add a patch.

Hello,

I've tried using the sudo cookbook to create a sudoers.d file for a user. I'd like to be able to run one command as root with no password.
The template creates a new sudoers.d file for me, but the user was still being prompted for a password. When I dug a bit further, it turned out that the template's format was creating this line:
user ALL=(ALL) :NOPASSWD /command/foo
where it should be writing this line:
user ALL= :NOPASSWD /command/foo

I've also tried adding a local template and running the sudo cookbook with this config:

sudo 'user' do
  template 'newsudoer.erb'
  variables( :cmds => ['/etc/init.d/service'] )
end

This, however, did not pick up the commands array as variables, and failed my kitchen run with the error:
NoMethodError: undefined method `each' for nil:NilClass

The current stack I'm working with is:
Chef Omibus 11.16.4
Chef Zero
and platform Ubuntu 14.04

As of now, I am locked in to my current chef version.
Any help / suggestions would be appreciated! Thanks!

Cookbook version

3.5.0

Chef-client version

13.x

Platform Details

All

Scenario:

#101 and #102 appears to have introduced a bug in the sudo resource. The intent was that if you were not using the sudo default recipe, you could just use the sudo resource to configure sudo users. So in adding the sudo package install to the sudo resource, it looks like a bug was introduced whereby the sudo package resource is happening during converge time and the sudo user configuration is occurring during compile phase:

  package 'sudo' do
    not_if 'which sudo'
  end

  unless ::File.exist?(target)
    sudoers_dir = directory target
    sudoers_dir.run_action(:create)
  end

Steps to Reproduce:

Use the sudo resource in an environment where sudo is not installed and the resource fails.

Expected Result:

I would expect for sudo resource not to fail as a result of not having sudo installed in your environment as the resource would install sudo and then configure the sudo user.

Actual Result:

    ================================================================================
    Error executing action `install` on resource 'sudo[made-up-user]'
    ================================================================================
    
    Errno::ENOENT
    -------------
    No such file or directory - visudo
    
    Cookbook Trace:
    ---------------
    /opt/kitchen/cache/cookbooks/sudo/providers/default.rb:49:in `validate_fragment!'
    /opt/kitchen/cache/cookbooks/sudo/providers/default.rb:104:in `render_sudoer'
    /opt/kitchen/cache/cookbooks/sudo/providers/default.rb:126:in `block in class_from_file'
    
    Resource Declaration:
    ---------------------
    # In /opt/kitchen/cache/cookbooks/chassis-users/recipes/default.rb
    
     23:     sudo user do
     24:       user user
     25:       nopasswd true
     26:     end
     27: 
    
    Compiled Resource:
    ------------------
    # Declared in /opt/kitchen/cache/cookbooks/chassis-users/recipes/default.rb:23:in `block in from_file'
    
    sudo("made-up-user") do
      action :install
      updated true
      updated_by_last_action true
      default_guard_interpreter :default
      supports {:report=>true, :exception=>true}
      declared_type :sudo
      cookbook_name "chassis-users"
      recipe_name "default"
      user "made-up-user"
      nopasswd true
    end
    
    System Info:
    ------------
    chef_version=13.0.118
    platform=ubuntu
    platform_version=16.04
    ruby=ruby 2.4.1p111 (2017-03-22 revision 58053) [x86_64-linux]
    program_name=chef-client worker: ppid=9;start=02:48:29;
    executable=/opt/chef/embedded/bin/chef-client

Hi,

this issue bytes me every other day:

When we include_recipe 'sudo' it automatically disables the sudoers.d include (which is enabled by default at least on ubuntu 12.04+14.04). Especially when doing tdd with test-kitchen/vagrant this usually "kills" the vm, because vagrant/test-kitchen users' sudo permissions (which are stored in sudoers.d) get removed (and we have to start over).

Setting default['authorization']['sudo']['include_sudoers_d'] within every cookbook/.kitchen.yml seems to be cumbersome.

How about changing the defautl['authorization']['sudo']['include_sudoers_d'] to true?

Is there a way to make the cookbook not touch /etc/sudoers?
I only want to use it to manage sudoers.d?
If not, I am willing to contribute code.
Have the template use to an attribute? authorization/sudo/dont_touch_etcsudoers=true
?

What is your preference?

Or am I the only person who has asked this?

Cookbook version

3.3.1

Chef-client version

12.18.31

Platform Details

Test Kitchen running rhel6 image in openstack

Scenario:

Test Kitchen configuration includes:

suites:
  - name: sudo
    run_list:
      - recipe[minitest-handler]
      - recipe[sudo]

Steps to Reproduce:

Run the above suite in Test Kitchen without setting any other defaults or overrides. This sets up the sudo::default recipe run with all cookbook defaults.

Expected Result:

/etc/sudoers should include a configuration for the %sysadmin group and NOPASSWD is not present.

%sysadmin ALL=(ALL)  ALL

Actual Result:

/etc/sudoers is changed to have these lines:

           +# Members of the group 'sysadmin' may gain root privileges
           +%sysadmin ALL=(ALL) NOPASSWD:ALL

Only when the attribute is set at a higher precedence does it render the right line in /etc/sudoers. For example, configure Test Kitchen, like this and it renders correctly:

suites:
  - name: sudo
    run_list:
      - recipe[minitest-handler]
      - recipe[sudo]
    attributes:
      authorization:
        sudo:
          passwordless: false

Cookbook version

3.5.0

Steps to Reproduce:

Visit webpage :)

Expected Result:

No HTML

Cookbook version

4.0.0

Chef-client version

13.6.4

Platform Details

centos 7

Scenario:

Cannot change permissions on /etc/sudoes.d to be more restrictive than 0755 because it is hardcoded in the directory resource. /etc/sudoers is not world readable by default (0440) so it makes sense that other sudo configuration should be able to be set using a more restrictive mode.

Steps to Reproduce:

Use recipe with sudoers.d attribute enabled (now default). /etc/sudoers.d permissions are forced to 0755.

Expected Result:

Would like the ability to define more restrictive mode.

Actual Result:

It's always 0755.

the setting of 0440 on /etc/sudoers prevents users from using sudo on centos7

kitchen@eef1cd73932e.      ~
$ sudo su -
sudo: unable to open /etc/sudoers: Permission denied
sudo: no valid sudoers sources found, quitting
sudo: unable to initialize policy plugin

user ALL=(ALL) NOPASSWD:ALL

See that double-space up there? That's significant, and breaks sudo silently. Is there meant to be a parameter there which has no value by default? I can't think of one..

Cookbook version

master HEAD

Chef-client version

N/A

Platform Details

N/A

Scenario:

Use of User_Alias from the cookbook

Steps to Reproduce:

There is no support for the User_Alias functionality in the template

Expected Result:

Like Cmnd_Alias User_Alias should take in a hash of node attributes and supply User_Alias sections to a sudoers file.

Actual Result:

Not possible as the template does not have support for this functionality.

Edit:
Also I should indicate I'm working on the PR for this right now.

Cookbook version

3.1.0

Mapping of the exception to a variable is missing in the this rescue clause.

Cookbook version

3.4.0

Chef-client version

12 & 13

Platform Details

All

Question:

If you are using the sudo resource without using the default recipe of the cookbook, should the resource also care for installing the sudo package if it is not already present? The reason I ask is that I work in a company where the sudo list is programmatically managed and is outside of the realm of my control. So I would not have the need to use the default recipe but do have the need for the sudo resource.

The ability to remove sudo access if it exist.

Example:
sudo 'developers' do
group 'developers'
nopasswd true
action remove
end

The problem is when there is no sudo package installed the validator (visudo) fails as it is not installed on the system.

Cookbook version

"version":"3.0.0"

Chef-client version

Chef: 12.9.41

Platform Details

"Debian GNU/Linux 8 (jessie)"

Scenario:

I'm trying to run cookbook LWRP:

node.default['authorization']['sudo']['sudoers_defaults'] = ['env_reset']
node.default['authorization']['sudo']['include_sudoers_d'] = true

sudo 'ops' do
  user      "ops"
  runas     'root'
  nopasswd  true
  commands  ["/usr/local/bin/indexer"]
end

Steps to Reproduce:

Run cookbook on platform without sudo pakcage installed or just purge the sudo package from the operation system.

Expected Result:

Converging 1 resources
Recipe: bkt::sudo
  * sudo[ops] action install
    * template[/etc/sudoers.d/ops] action create
      - update content in file /etc/sudoers.d/ops from c3255c to 021371
      --- /etc/sudoers.d/ops    2016-09-30 10:49:20.543075000 +0300
      +++ /etc/sudoers.d/.chef-ops20160930-7501-1iow7bt 2016-09-30 10:51:04.807075000 +0300
      @@ -1,2 +1,9 @@
      +# This file is managed by Chef.
      +# Do NOT modify this file directly.
      +
      +
      +
      +
       ops ALL=(root) NOPASSWD:/usr/local/bin/indexer
      +
      - change mode from '0644' to '0440'
    * template[/etc/sudoers.d/ops] action nothing (skipped due to action :nothing)


Running handlers:
Running handlers complete
Chef Client finished, 2/3 resources updated in 33 seconds

Actual Result:

Converging 1 resources
Recipe: bkt::sudo
  * sudo[ops] action install

    ================================================================================
    Error executing action `install` on resource 'sudo[ops]'
    ================================================================================

    Errno::ENOENT
    -------------
    No such file or directory - visudo

    Cookbook Trace:
    ---------------
    /root/chef/.chef/local-mode-cache/cache/cookbooks/sudo/providers/default.rb:49:in `validate_fragment!'
    /root/chef/.chef/local-mode-cache/cache/cookbooks/sudo/providers/default.rb:104:in `render_sudoer'
    /root/chef/.chef/local-mode-cache/cache/cookbooks/sudo/providers/default.rb:122:in `block in class_from_file'
    /root/chef/.chef/local-mode-cache/cache/cookbooks/compat_resource/files/lib/chef_compat/monkeypatches/chef/runner.rb:41:in `run_action'

    Resource Declaration:
    ---------------------
    # In /root/chef/.chef/local-mode-cache/cache/cookbooks/bkt/recipes/sudo.rb

     10: sudo 'ops' do
     11:   user      "ops"
     12:   runas     'root'
     13:   nopasswd  true
     14:   commands  ["/usr/local/bin/indexer"]
     15: end

    Compiled Resource:
    ------------------
    # Declared in /root/chef/.chef/local-mode-cache/cache/cookbooks/bkt/recipes/sudo.rb:10:in `from_file'

    sudo("ops") do
      action :install
      supports {:report=>true, :exception=>true}
      retries 0
      retry_delay 2
      default_guard_interpreter :default
      declared_type :sudo
      cookbook_name "bkt"
      recipe_name "sudo"
      user "ops"
      runas "root"
      nopasswd true
      commands ["/usr/local/bin/indexer"]
      host "ALL"
    end

    Platform:
    ---------
    x86_64-linux


Running handlers:
[2016-09-30T10:55:33+03:00] ERROR: Running exception handlers
Running handlers complete
[2016-09-30T10:55:33+03:00] ERROR: Exception handlers complete
Chef Client failed. 0 resources updated in 31 seconds
[2016-09-30T10:55:33+03:00] FATAL: Stacktrace dumped to /root/chef/.chef/local-mode-cache/cache/chef-stacktrace.out
[2016-09-30T10:55:33+03:00] FATAL: Please provide the contents of the stacktrace.out file if you file a bug report
[2016-09-30T10:55:33+03:00] ERROR: sudo[ops] (bkt::sudo line 10) had an error: Errno::ENOENT: No such file or directory - visudo
[2016-09-30T10:55:35+03:00] FATAL: Chef::Exceptions::ChildConvergeError: Chef run process exited unsuccessfully (exit code 1)

Cookbook version

4.0.1+

Chef-client version

chef 12.22.1

Platform Details

Ubuntu 16.04

Scenario:

my Chefspec tests are failing because the install_sudo and remove_sudo matchers have been removed in version 4.0.1.

Steps to Reproduce:

any cookbook depending on this cookbook that uses install_sudo chefspec matchers will have failing tests

Expected Result:

successful chefspec tests :)

Actual Result:

failing chefspec tests

I am not sure what setting node['authorization']['sudo']['include_sudoers_d'] to true actually does. With using the LWRP, I am receiving the warning however that the user is rendered but the rule will not work because node['authorization']['sudo']['include_sudoers_d'] is set to false but the rule still works.

Can someone provide clarification on what this actually does?

Thanks!

Is this cookbook being deprecated with the sudo resource now in chef 14? If so it's missing it's deprecation warning in supermarket and Readme.

Cookbook version

[Version of the cookbook where you are encountering the issue]
2.11.0

Chef-client version

[Version of chef-client in your environment]
Chef: 12.8.1

Platform Details

[Operating system distribution and release version. Cloud provider if running in the cloud]
Red Hat Enterprise Linux Server release 7.2 (Maipo)

Scenario:

[What you are trying to achieve and you can't?]
Create a user scm and convert it to sudoer

Steps to Reproduce:

[If you are filing an issue what are the things we need to do in order to repro your problem? How are you using this cookbook or any resources it includes?]

metadata.rb:

depends 'sudo'   # add the dependency to use sudo cookbook

attribute/default.rb
# Add the defined user 'scm' to sudo
default['il']['user'] = 'scm'
default['authorization']['sudo']['users'] << default['il']['user']

# Add a group for the 'scm' user
default['il']['group'] = 'scm'

# RHEL family 7.x sudoer default
default['authorization']['sudo']['sudoers_defaults'] = [
  'requiretty',
  '!visiblepw',
  'env_reset',
  'env_keep =  "COLORS DISPLAY HOSTNAME HISTSIZE INPUTRC KDEDIR LS_COLORS"',
  'env_keep += "MAIL PS1 PS2 QTDIR USERNAME LANG LC_ADDRESS LC_CTYPE"',
  'env_keep += "LC_COLLATE LC_IDENTIFICATION LC_MEASUREMENT LC_MESSAGES"',
  'env_keep += "LC_MONETARY LC_NAME LC_NUMERIC LC_PAPER LC_TELEPHONE"',
  'env_keep += "LC_TIME LC_ALL LANGUAGE LINGUAS _XKB_CHARSET XAUTHORITY"',
  'always_set_home',
  'secure_path = /sbin:/bin:/usr/sbin:/usr/bin'
]

# Use the sudo LWRP as it relies on the "#includedir" directive
# introduced in version 1.7.2
default['authorization']['sudo']['include_sudoers_d'] = true

# Do not add any sudo group
default['authorization']['sudo']['groups'] = []

recipes/default.rb

if node['platform_family'] == 'rhel' and node['platform_version'].start_with?("7")
  include_recipe 'user'
end

recipes/user.rb

# Create scm user that is converted to sudo user using sudo cookbook
user_home = "/home/#{node['il']['user']}"

user node['il']['user'] do
    supports :manage_home => true
    uid '1000'
    gid '1000'
    home user_home
    shell '/bin/bash'
    password '$6$b3Fz1KK9$88mZBw93PLUagyaljq3fbLQXcc5OfWFb6HjGQPrIjcA15qL2qDcBmFRhnf9a0qd8gl8Jo9/1wwTKel7qdM59x/'
    action :nothing
end

group node['il']['group'] do
    append true
    gid '1000'
    notifies :create, "user[#{node['il']['user']}]", :immediately
    action :create
end


sudo node['il']['user'] do
    user "#{node['il']['user']}"
end

# include the sudo recipe to take advantages of the attributes above.
include_recipe 'sudo'

Expected Result:

[What are you expecting to happen as the consequence of above reproduction steps?]

Only see sudoer.d/scm

scm:

# This file is managed by Chef.
# Do NOT modify this file directly.




scm ALL=(ALL) ALL

### Actual Result:
[What actually happens after the reproduction steps? Include the error output or a link to a gist if possible.]

both sudoer file and sudoer.d/scm get added for scm.

sudoer:

# This file is managed by Chef.
# Do NOT modify this file directly.

Defaults      requiretty
Defaults      !visiblepw
Defaults      env_reset
Defaults      env_keep =  "COLORS DISPLAY HOSTNAME HISTSIZE INPUTRC KDEDIR LS_COLORS"
Defaults      env_keep += "MAIL PS1 PS2 QTDIR USERNAME LANG LC_ADDRESS LC_CTYPE"
Defaults      env_keep += "LC_COLLATE LC_IDENTIFICATION LC_MEASUREMENT LC_MESSAGES"
Defaults      env_keep += "LC_MONETARY LC_NAME LC_NUMERIC LC_PAPER LC_TELEPHONE"
Defaults      env_keep += "LC_TIME LC_ALL LANGUAGE LINGUAS _XKB_CHARSET XAUTHORITY"
Defaults      always_set_home
Defaults      secure_path = /sbin:/bin:/usr/sbin:/usr/bin

# User privilege specification
root          ALL=(ALL) ALL


scm ALL=(ALL) ALL


# This is not a comment; see sudoers(5) for more information on "#include" directives
#includedir /etc/sudoers.d

https://github.com/opscode-cookbooks/sudo/blob/master/Rakefile#L9

L9 should be changed to:
RuboCop::RakeTask.new(:ruby)

I ran into a problem where I could not set Default:root !requiretty. It's straightforward to set global defaults, but we do have a need to set user-specific defaults.