# User handling logic

**URL:** <https://discourse.chef.io/t/user-handling-logic/4985>\
**Category:** Chef Infra (archive)\
**Created:** [February 7, 2014, 11:45am UTC](https://discourse.chef.io/t/user-handling-logic/4985 "2014-02-07T11:45:17Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![Leonard\_Messier](https://avatars.discourse-cdn.com/v4/letter/l/e9bcb4/32.png) [@Leonard\_Messier](https://discourse.chef.io/u/Leonard_Messier)\
**Post date:** [February 7, 2014, 11:45am UTC](https://discourse.chef.io/t/user-handling-logic/4985/1 "2014-02-07T11:45:17Z")

</div>

Hi there,

I’m facing an issue related to the way I’m supposed to handle users on the  
machine I’m provisioning with chef-solo.

Since it is a physical machine, the user I’m using was created during  
installation. I would like to go on using this user.

In the past, I used to launch chef-solo with sudo because it was simpler to  
achieve what I wanted to do.  
Since I’ve started to include rspec testing in my process, I can’t use sudo  
directly anymore : I relied on “#{ENV[‘SUDO\_USER’]}” in my recipes to set  
the proper user and group, which is not available anymore with rspec and I  
don’t think it’s a good idea to launch rspec as sudo.

Now, I’m trying to find a way to handle this logically. Obviously, I need  
my user to have sudo access. My first move was to include the sudo  
community cookbook. However, i’m kind of stuck here because the chef run  
needs to have sudo privileges to create the sudoers file.

Am I supposed to have a one item run list that does this small step,  
launching chef-solo as sudo ?

–  
Léonard Messier

---

<div class="post-metadata">

**Author:** ![Dan\_Razzell](https://avatars.discourse-cdn.com/v4/letter/d/ed655f/32.png) [@Dan\_Razzell](https://discourse.chef.io/u/Dan_Razzell)\
**Post date:** [February 7, 2014, 11:15pm UTC](https://discourse.chef.io/t/user-handling-logic/4985/2 "2014-02-07T23:15:52Z")

</div>

Basically, yes, at least if you want to express the goal within Chef.  
Though, given that you've set up the user external to Chef anyway, that  
might be a more congruent point to add to sudoers. Logically, it's a  
property of the user account, just that for historical reasons it isn't  
recorded along with the account.

Then you'll have your main Chef session running as the specified working  
user. But even though that user is now in sudoers, it doesn't have root  
privileges itself. Therefore all of the resources where you might want  
to specify a user/owner/group attribute other than the working user, say  
root for example, will not work.

This includes bash and execute as well. Though you can get the desired  
effect by defining their command attribute as a sudo command, you're  
leaving Chef behind at that point.

All in all, unless the scope of what you want to do is genuinely limited  
to that working user, you might want to run Chef as root and then  
specify user/owner/group attributes wherever you want a more restricted  
effect. This will work as expected (except for recursive directory  
creation which has unusual semantics in Chef).

If you want to run bash by default as the specified user, our solution  
here was to extend the bash provider as something we call bash\_strict.  
It's defined in a library file and looks like this:

require "chef/resource/script"

class Chef  
class Resource  
class BashStrict \< Chef::Resource::Script

```
   def initialize(name, run_context=nil)
     super
     @resource_name = :bash_strict
     @interpreter = "bash"
     @flags = "-e"
     @user = "your default user goes here"
     @group = "your default group goes here"
     @verbose = nil
   end

 end

```

end  
end

Hope you find this useful.

Dan

On 14-02-07 03:45 AM, Leonard Messier wrote:

> Hi there,
> 
> I'm facing an issue related to the way I'm supposed to handle users on  
> the machine I'm provisioning with chef-solo.
> 
> Since it is a physical machine, the user I'm using was created during  
> installation. I would like to go on using this user.
> 
> In the past, I used to launch chef-solo with sudo because it was  
> simpler to achieve what I wanted to do.  
> Since I've started to include rspec testing in my process, I can't use  
> sudo directly anymore : I relied on "#{ENV['SUDO\_USER']}" in my  
> recipes to set the proper user and group, which is not available  
> anymore with rspec and I don't think it's a good idea to launch rspec  
> as sudo.
> 
> Now, I'm trying to find a way to handle this logically. Obviously, I  
> need my user to have sudo access. My first move was to include the  
> sudo community cookbook. However, i'm kind of stuck here because the  
> chef run needs to have sudo privileges to create the sudoers file.
> 
> Am I supposed to have a one item run list that does this small step,  
> launching chef-solo as sudo ?
> 
> --  
> Léonard Messier

---

<div class="post-metadata">

**Author:** ![Leonard\_Messier](https://avatars.discourse-cdn.com/v4/letter/l/e9bcb4/32.png) [@Leonard\_Messier](https://discourse.chef.io/u/Leonard_Messier)\
**Post date:** [February 10, 2014, 12:41pm UTC](https://discourse.chef.io/t/user-handling-logic/4985/3 "2014-02-10T12:41:53Z")

</div>

Thanks Dan,

Your solution is interesting but I don't think it will easily apply to my  
solution.

I think I have a conception problem.

As you pointed out, my user is set prior to any chef execution. I think I  
should keep the dummy user from my base installation and create my real  
user with chef.

That way, I can stick with using sudo to launch the chef-solo command and  
use data bags to configure users. In my recipes, instead of hard coding the  
user and group value or using an environment variable like SUDO\_USER, I  
could loop on the users data bag and apply resources for each user,  
allowing for future user creation.

What do you think of it ?

Léonard Messier

2014-02-08 0:15 GMT+01:00 Dan Razzell [danr@activestate.com](mailto:danr@activestate.com):

> Basically, yes, at least if you want to express the goal within Chef.  
> Though, given that you've set up the user external to Chef anyway, that  
> might be a more congruent point to add to sudoers. Logically, it's a  
> property of the user account, just that for historical reasons it isn't  
> recorded along with the account.
> 
> Then you'll have your main Chef session running as the specified working  
> user. But even though that user is now in sudoers, it doesn't have root  
> privileges itself. Therefore all of the resources where you might want to  
> specify a user/owner/group attribute other than the working user, say root  
> for example, will not work.
> 
> This includes bash and execute as well. Though you can get the desired  
> effect by defining their command attribute as a sudo command, you're  
> leaving Chef behind at that point.
> 
> All in all, unless the scope of what you want to do is genuinely limited  
> to that working user, you might want to run Chef as root and then specify  
> user/owner/group attributes wherever you want a more restricted effect.  
> This will work as expected (except for recursive directory creation which  
> has unusual semantics in Chef).
> 
> If you want to run bash by default as the specified user, our solution  
> here was to extend the bash provider as something we call bash\_strict.  
> It's defined in a library file and looks like this:
> 
> require "chef/resource/script"
> 
> class Chef  
> class Resource  
> class BashStrict \< Chef::Resource::Script
> 
> ```
> def initialize(name, run_context=nil)
> super
> @resource_name = :bash_strict
> @interpreter = "bash"
> @flags = "-e"
> @user = "your default user goes here"
> @group = "your default group goes here"
> @verbose = nil
> end
> 
> end
> 
> ```
> 
> end  
> end
> 
> Hope you find this useful.
> 
> Dan
> 
> On 14-02-07 03:45 AM, Leonard Messier wrote:
> 
> > Hi there,
> > 
> > I'm facing an issue related to the way I'm supposed to handle users on  
> > the machine I'm provisioning with chef-solo.
> > 
> > Since it is a physical machine, the user I'm using was created during  
> > installation. I would like to go on using this user.
> > 
> > In the past, I used to launch chef-solo with sudo because it was simpler  
> > to achieve what I wanted to do.  
> > Since I've started to include rspec testing in my process, I can't use  
> > sudo directly anymore : I relied on "#{ENV['SUDO\_USER']}" in my recipes to  
> > set the proper user and group, which is not available anymore with rspec  
> > and I don't think it's a good idea to launch rspec as sudo.
> > 
> > Now, I'm trying to find a way to handle this logically. Obviously, I need  
> > my user to have sudo access. My first move was to include the sudo  
> > community cookbook. However, i'm kind of stuck here because the chef run  
> > needs to have sudo privileges to create the sudoers file.
> > 
> > Am I supposed to have a one item run list that does this small step,  
> > launching chef-solo as sudo ?
> > 
> > --  
> > Léonard Messier

--  
Léonard Messier  
Développeur web PHP/Javascript/MySQL  
[http://www.leonardmessier.com](http://www.leonardmessier.com)