Showing posts with label permissions. Show all posts
Showing posts with label permissions. Show all posts

Saturday, December 3, 2016

Assigning default ownership to all new files in a directory

Getting the hang of Linux file-system permissions can be tricky for beginners. I still have problems every now and again translating symbolic permission notation to octal permission notation and back again. One common scenario which can be complicated to enact in practice is the creation of default permissions for files inside of given directories. Although not a direct translation, in Windows this sort of functionality is usually implemented by selecting the "Allow propagation on child objects" setting when viewing Security Properties for a directory. But how to get this done in Linux?

The preferred approach is the use of Access Control Lists using setfacl. Since Linux kernel 2.6, the acl flag is enabled by default with most standard filesystems. There's already several solid explanations for how to use Linux ACLs. But, there are scenarios in which this can be difficult or impossible to implement; using exotic filesystems or older kernels, etc. Or you just might find ACL syntax confusing and try to avoid it unless absolutely needed. Whatever the reason, if all you need is to have all files in a given directory owned by a specific group and/or assigned a specific set of permissions, here's a down and dirty way to do it using a set-group-id bit.

umask 002 /somedirectory/              ### With this mask default subdirectory permissions are 775
                                                         ###  and default file permissions are 664 (-rw-rw-r--)
chgrp somegroup /somedirectory/   ### here we assign our preferred group
chmod g+s /somedirectory/             ### here we assign a set-group-id bit to the directory

Keep in mind that the umask in this example is pretty wide open. If you're not familiar with umask, take a look at one of the many guides floating around. I am much more likely to use a umask of 022 or 077 in production than the above example.

Thursday, June 14, 2012

Changes to Helicon Ape's http.conf Not Recognized? Check Permissions

Helicon Ape is a great tool that allows people to stop complaining that Windows does not provide support for .htaccess, or for those who need URL rewriting in pre-Windows 2008 servers.

For maximum confusion, Helicon names its configuration file httpd.conf like Apache. I made some modifications to the logging verbosity in that file, helping out an admin who hadn't realized that debug-level verbosity on redirect logging results not just in poor performance from the additional overhead needed to write to a file each time a URL is mod'd, but in a huge file that will quickly overwhelm available storage. Attempting to save http.conf resulted in errors because it was in use by a process so I copied my modified file to the desktop, renamed the existing conf file and copied my copy back into the Helicon configuration directory. 

My changes weren't applied. The syntax was correct in my changes and Helicon kept processing redirects. Sure enough I compared permissions on the two files and the NETWORK service user had been stripped from my modified file. Propagating the correct permissions allowed the file to be read and the changes applied. 

My complaint: helicon continued to run without access to the file, so why is a process lock required? Let me modify my files and deal with the consequences. As an aside, I highly recommend Unlocker, a lightweight application that overrides overzealous process locks and comes with an available and invaluable addition to your right-click context menu.

Saturday, May 19, 2012

MySQL root Grants Broken Following a phpmyadmin Install in Windows

So this is a weird one. I recently installed phpmyadmin 3.5.1 in a MySQL 5.1 / IIS 7.5 environment. Everything was going well until I realized that following the installation (which was fully functional) I could not login to MySQL (from the CLI) without referencing the hostname (-h flag). I figured that maybe the .sql script included with the installer messed with my grants, but a quick show grants revealed I still had the same permissions granted to root as when I started. So I figured that I would update the grants on root to what was displayed in show grants just in case. This produced an insufficient permissions error even though root had "full" privileges.

To resolve this I added skip-grant-tables to my.ini, restarted the mysql service, logged in as root, flushed privileges, and again updated grants to what was displayed in "show grants". I then removed skip-grant-tables and restarted, and I was again able to login locally. I'm still not certain what caused this and there was of course no relevant data in the logs. If anyone has any ideas I would definitely appreciate feedback in the comments!