Hi Adam,
As you’d expect, we have a system installation of Chef that we use in the normal way to perform system-level configuration.
In addition, for each user we start Chef at login to perform initial profile configuration. As part of a run, Chef creates a scheduled task to run itself once per day if the user is logged in, and provides the user a shortcut to run Chef on demand if they need a configuration update sooner. I chose this approach over trying to put the configuration in place with a set of system-level scripts, as tasks like writing a user’s registry keys and performing the initial configuration at first login are more complex to do that way.
I understand that this is a niche use-case, and am happy to run user-level Chef instances with file_atomic_update=false. Aside from the Directory resource, this allowed our existing recipes to complete convergence. However, if you want me to create a bug about this then I am willing to - although my time is about to become very scarce again!
Dan.
From: Adam Edwards [mailto:adamed@opscode.com]
Sent: 03 January 2014 00:52
To: Daniel Oliver; chef@lists.opscode.com
Cc: kkeane.com@sendgrid.info
Subject: RE: [chef] RE: RE: Chef-client as unprivileged Windows user
Interesting. I agree that if the account in question has the correct privileges to do something it should work - many of the things that people do with Chef on Windows, such as install software packages, modify config files like drivers/etc/hosts, or set registry keys in HKEY_LOCAL_MACHINE, will require admin privileges (unless the system was modified from the default configuration in some way with looser permissions).
The case you give of modifying a file to which the user running Chef has full control is one where things should work. I think in addition to the culprits you lay out (various compat / virtualization subsystems, including wow64’s little tricks), there could be a bug in Chef where it is simply asking for too many permissions (e.g. people calling CreateFileEx asking for read / write access to a file when they are just trying to read a file), or not adding a required privilege into the token (there are a few operations that require an explicit modification of the thread / process token via AdjustTokenPrivileges).
Your use case is fairly new to me - sounds like you have non-admin users who are logging in to a system, and you’re running chef-client as those users on their first login so you can configure the profiles?
-Adam
From: Daniel Oliver [mailto:Daniel.Oliver@contextis.co.ukmailto:Daniel.Oliver@contextis.co.uk]
Sent: Monday, December 30, 2013 6:09 AM
To: chef@lists.opscode.commailto:chef@lists.opscode.com
Cc: kkeane.com@sendgrid.infomailto:kkeane.com@sendgrid.info; adamed@opscode.commailto:adamed@opscode.com
Subject: RE: [chef] RE: RE: Chef-client as unprivileged Windows user
Hi list,
While 90% of our users are out of the office, I’ve found time to sit down with and look further at running Chef 11 as an unprivileged user. After hours sitting with the like of Process Monitor, I still can’t understand why chef is unable to manipulate the permissions on files for which the current user has full control and is the owner. The failure is when attempting to read the security descriptor of the destination file so that they can be replicated to the new template; the API call is denied by Windows, although icacls is able to make the same call and succeed. I think it must be related to the application compatibility/virtualisation layers, but I can’t find any setting that will change the behaviour - if indeed there is one!
So I decided to work around the problem and write a new provider that wouldn’t attempt to perform permissions manipulation in the problematic cases. However, in doing so found the file_atomic_update setting. Setting this to false causes Chef uses the Cp provider, which “just works” for the use cases in which I am interested (generating client side configuration files on a per-user basis), as it doesn’t attempt any permissions manipulation unless explicitly specified in the resource.
FYI, I also had problems with the Directory resource, which I just replaced with calls to Dir.mkdir().
Thanks for your replies, and my apologies for the very delayed feedback. Onwards to Chef 11!
Dan.
From: Adam Edwards [mailto:adamed@opscode.com]
Sent: 10 October 2013 21:08
To: chef@lists.opscode.commailto:chef@lists.opscode.com
Subject: [chef] RE: RE: Chef-client as unprivileged Windows user
Hello Dan - there aren’t any changes from chef-client 10 to chef-client 11 that should affect Windows unprivileged users. There is a warning however that you may see in log output indicating that you’re better off running with full privileges.
So if things worked for you with chef-client 10, they will probably work fine on chef-client 11; if that is indeed true for you, you can ignore the warning in the logs, which is aimed at unblocking people who hit issues that could be fixed by running with full privileges. That said, as Kevin suggests, there are a lot of things that won’t work in you don’t have full privileges - this is due to restrictions (correctly) built in to Windows, not really a limitation in Chef - chef-client won’t allow the security model of Windows to be circumvented.
For example, if you have a recipe that adds a new user to a Windows system, that recipe will fail unless chef-client is executed as a user with full privileges. The “fix” is to run with full privileges, or since its Windows, configure the system / user account such that it has exactly the privileges you need for your specific recipes to succeed.
-Adam
From: subscription=kkeane.com@sendgrid.infomailto:subscription=kkeane.com@sendgrid.info [mailto:subscription=kkeane.com@sendgrid.info] On Behalf Of Kevin Keane Subscription
Sent: Thursday, October 10, 2013 1:38 AM
To: chef@lists.opscode.commailto:chef@lists.opscode.com
Subject: [chef] RE: Chef-client as unprivileged Windows user
First of all, you mention that you are migrating from Chef 10 to Chef 11. Are you talking about migrating the server, or the client? Migrating the server really shouldn’t make a difference; migrating the client might.
My best guess is that the permission problems aren’t with the final file location, but rather with the Chef cache directory (or one of the other directories the Chef client uses). It is also possible that the problem arises because Chef doesn’t actually create the file, but move it. Chef actually doesn’t create templatized files in place. Rather, it builds the templatized files in a temporary location (I think it’s actually the cache directory, but I’m not sure off the top of my head), computes the file hash, and then computes the hash of the existing file (only if a file already exists, of course). If the two hashes don’t match, Chef then moves the file from the temporary location to its final place.
Generally, Chef was not really designed to run with limited permissions. I’m actually impressed that you manage to run it to set up per-user configurations; it’s something I’d also love to be able to accomplish!
Kevin Keane
The NetTech
760-721-8339
http://www.4nettech.com
Our values: Privacy, Liberty, Justice
See https://www.4nettech.com/corp/the-nettech-values.html
-----Original message-----
From: Daniel Oliver <Daniel.Oliver@contextis.co.ukmailto:Daniel.Oliver@contextis.co.uk>
Sent: Thursday 10th October 2013 1:17
To: chef@lists.opscode.commailto:chef@lists.opscode.com
Subject: [chef] Chef-client as unprivileged Windows user
Hi list,
I’m sorry if this question has been asked before, but I can’t find in my archives. I am testing our migration from Chef 10 to 11, and things have been ok the server and system side. Unfortunately, I’ve hit a road-block when it comes to unprivileged Windows users.
We use Chef to perform various configuration tasks in each of our user profiles, such as dropping per-user configuration files into the correct location at login and periodically thereafter using a scheduled task. Unfortunately, I have been unable to make Chef 11.6 deploy even the simplest template to a user’s profile; I just keep file security permission errors. I have tried varying absolute/relative paths, Windows/Unix style directories and combinations of Windows/Unix permission options, all with no success.
I do see a 0-byte file appear, for which the current user is the owner having full control, and I am able to change permissions using Explorer.
I’ve looked through mv_windows.rb, and I understand why the permissions handling has been implemented as it has realise that this may well introduce some scenarios I need to work around. However, what I don’t understand is why it isn’t working in this situation? My user is able to manipulate the file permissions in Explorer with no privilege escalation, and the location I am trying to write to is not subject to redirection by the Virtual Store. Chef is also creating a 0-byte file with the current user as the owner and explicit full control.
If anyone can shed some light on this problem, I would really appreciate your input.
Thanks,
Dan.