Friday, November 6, 2009

Thank You Internet

More Linux stuff in this post. If you don't really care, then go ahead and skip, I'll only hold it against you for the rest of your life.

There's lots of fixed-width-font formatting in here that won't be visible unless you're actually reading it on my blog. It really adds a lot of helpful emphasis, so your opinion of my technical writing should go up by reading it with that emphasis intact. (and down from the sheer number of parenthetical statements, but whatever)

So after successfully getting my server set up and running lean and mean with ArchLinux, I figured it was time to pimp it a bit. I wanted to see if I could get Samba working (Samba = the Windows Network file-sharing protocol) so I could have a directory be remotely accessible from a Windows computer with no password (i.e. a public share, necessary to make drop boxes and stuff).

Samba's configuration has way more options than are initially in smb.conf but eventually I got it. So now I have a subdirectory in my home directory (aptly named "share", though it appears on the network as "eckstee" because that's what I named its section in smb.conf.) shared with no password, and I can browse to it on Windows and read (and even modify, since I allowed write permissions) the file I stuck in it (named youfoundit.txt).

That actually happened several days ago. What just happened tonight, however, was something that I'd wanted to do for a while but never really knew how to do.

When you install Apache, there's a certain directory set as its document root (configured by the aptly-named DocumentRoot directive in httpd.conf) that files are loaded from when you request http://servername/filename.ext. This directory (/srv/http/ on ArchLinux), by default, has its permissions set so you have to be root in order to create or modify anything in it. Now, there isn't really that much of a problem there, since I know my root password, but I really don't want to be doing things as root with full root privileges. Bad Things™ can happen when you do that.

So I said to myself, "I'll just make a group called 'webdev', stick my account in it, then configure the permissions on that directory so anyone in the group webdev has write permissions!"

The first part of this was relatively easy. Made the webdev group, stuck my account in it, changed the group on the directory to webdev, chmod'ed it to 775, then logged out and back in for the group change to take effect. I can now create and modify files in the directory using my normal account.

Then the problems arose. First off, the group owning the new files I was creating to test was the primary group my account was in, users, instead of webdev. That was easily fixed with chmod by setting the setgid bit on the directory. For reference the command is chmod g+s directoryname. You could do it with octal (it would be chmod 2775 directoryname), but using octal obliterates existing permissions whereas the letter syntax leaves them alone. Now when I make new files, webdev owns them and the proper permissions can take effect.

The second problem was just that: permissions. The default permissions are read/write for owner, and read only for the group on the directory and for everyone else. I wanted the permissions in this directory and this directory alone to default to both the owner and the group having read/write.

A quick Google search told me I'd have to use an ACL to make this happen, and even showed some sample commands designed to do just this. Except that the command (modified for what I was trying to do, of course) wouldn't work. Every time I ran it I got an error message saying I hadn't provided enough arguments.

Some more Google searching with the proper command name (I had searched 'umask', not 'setfacl', silly me) found me the reason why my attempts at setting up an ACL weren't working. There's a mount option you have to set on that partition in /etc/fstab (aptly named acl) to actually enable them. So I did that and rebooted (I probably could have just told mount to remount the root partition, but rebooting works too), and then after some slight facepalmery, the command succeeded.

I made a new file and crossed my fingers. One ls -l later, I was pleased to see that the new file had the exact permission set I wanted. Running getfacl on the directory now shows that for the group webdev, permissions are overridden so that group read/write are always available.

So in case anyone else happens to want to do this (I ran across a few forum posts in my Google searches where people were asking how to do exactly this), here's a quick reference. You'll have to do most if not all of this as root. If you're a lower-level linuxmancer like myself, look all the commands (and the one file) up with man before doing anything. Also of interest would be mount's man page.
  1. In /etc/fstab, make sure the partition containing the directory you want to change default permissions on has the acl mount option.
  2. Remount the partition, or if you're lazy and/or a BOFH, reboot.
  3. Make a new group with groupadd, then put your account (and any other accounts you want to be in the group) into the group with groupmems.
  4. If any of those accounts are logged in, log them out and back in (or tell people to do that if you're in a multi-user setting). Once this has happened, running groups as the user(s) you added to the group should return a list of groups including the group you just created. For instance, mine returns users webdev.
  5. Change the group on the desired directory to the one you just set up, using chgrp.
  6. Change the permissions on the directory to have the group write and setgid permissions bits set. Easy way out = chmod g+ws directoryname.
  7. Now use setfacl to tell it that the group permissions for all new files should be rw-. Your command should look something like this: setfacl -d -m group:groupname:rw- directoryname.
Now if you ls -ld directoryname, you should see something similar to this: drwxrwsr-x+ 2 owner groupname 4096 2009-11-06 00:13 directoryname. The s in the group bits indicates setgid, and the + indicates that there's an ACL in effect on the directory. You can view the ACL with getfacl directoryname. Any files created in the directory after this will also have a + at the end of their permissions bits. You'll have to chmod and setfacl existing files and directories to the appropriate values manually. Keep in mind that both chmod and setfacl take the -R argument which makes them recurse subdirectories, so keep that in mind if you've got a large directory structure and you just said "fuck my life!" because you thought you'd have to manually chmod and setfacl everything.

Important to note is that so long as you don't fuck with the everyone read permission, Apache will still be able to serve files from the directory. So basically it Just Works™. And I like that.

On a non-Linux note, I'm going to Nekocon this weekend, so expect a con report late Sunday evening/early Monday morning.

No comments:

Post a Comment

I moderate comments because when Blogger originally implemented a spam filter it wouldn't work without comment moderation enabled. So if your comment doesn't show up right away, that would be why.