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:
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 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. 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 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 Our values: Privacy, Liberty, Justice See https://www.4nettech.com/corp/the-nettech-values.html
|
Archive powered by MHonArc 2.6.16.