Symlinks and Stuff

Let's say one has a gmid server, and wants to add user specific directories. How hard could this be?

Directory Under Gemini

One way to do this is to make user directories within the gemini tree, give the user permissions to that directory, and to make a symlink from the user's home directory over to the gemini tree for easy access. Let's say cousin Clem needs access.

    # cd /var/gemini/thrig.me
    # mkdir -p user/clem
    # chown clem:clem user/clem
    # ln -s `pwd`/user/clem ~clem/gemini
    # ls -ld user/clem
    drwxr-xr-x  2 clem  clem  512 Jan  5 23:00 user/clem
    # ls -l ~clem/gemini
    lrwxr-xr-x  1 clem  clem  37 Jan  5 23:00 /home/clem/gemini -> /var/gemini/thrig.me/user/clem

Directory Under User's Homedir

Another option is to make a gemini directory under the user's home directory, then to link to that from the gemini tree. This, however, can be problematic (see below). Assuming that the above commands have not be run:

    # cd /var/gemini/thrig.me 
    # mkdir user
    # mkdir ~clem/gemini
    # chown clem:clem ~clem/gemini
    # ln -s ~clem/gemini user/clem
    # ls -ld ~clem/gemini
    drwxr-xr-x  2 clem  clem  512 Jan  5 23:16 /home/clem/gemini
    # ls -l user/clem      
    lrwxr-xr-x  1 root  wheel  19 Jan  5 23:17 user/clem -> /home/clem/gemini

If your "->" symlinks don't look the same, or fail, then you've gone done something wrong. Some folks forever get the order of the arguments wrong; maybe use a wrapper program with --from and --to that gets it right for you, or invent a memorable mnemonic?

Fully qualifying all the paths involved can help avoid dangling symlinks that don't work right. Hence the pwd/blah/blah thing I used above to fully qualify the path.

A Problem

One problem with "Directory Under User's Homedir" is that gmid may use a chroot, in which case gmid can only "see" /var/gemini and files directly under that tree. If a symlink points outside the chroot, then gmid cannot follow that. That is, "Directory Under Gemini" is a better plan if chroot is enabled, and probably what I'd default to using.

A chroot is no good if an attacker can simply symlink out of it, like some hero does in Snow Crash (okay it wasn't a chroot, but was a sword wall thing in something like second life, spoilers, etc. Maybe they should have used some defense in depth to prevent such sword tricks from going too far?)

However, backups may be complicated if some of the user's files are not in their home directory, and are instead off under /var/gemini or whatever. Trade-offs! (Also, are you backing up their crontab files, or mail folders, and other such tricky things that may not be under their home directory?)

Another Problem

If you're on OpenBSD, you can mostly ignore this section, unless you have users fiddling around with their umasks and chmods and chowns, then you may need to pay some attention. The unix permissions model is very, very simple, and yet users can screw it up very, very much. Windows? A windows admin was all "err, um, well, you see, look—squirrel!" when I asked about fixing a shared drive permissions problem.

Still with me? Okay. On linux, there can be a problem where when a user creates sub-directories, those new directories inherit not from the parent directory, but rather from the process making the mkdir call. (It's a System V thing, and linux has taken some things from System V, and others BSD.) So you may need to fudge the permission or group back to that of the parent process (what a BSD filesystem correctly does by default), or to mount the filesystem with BSD semantics, if the filesystem supports that.

(I'm being vague here because I forget if it was the group or the permissions or what, and I'm too lazy to go digging around in the docs, and am not motivated enough to find a linux system to test on.)

One way to test this would be to have the user make some sub-directories, then check that the permission, owner, and group are correct. The umask can also be a problem, if gmid lacks the rights to read the user's files. Gmid files are probably public, so o+r permissions read for files and o+rx for directories may be necessary, in addition to whatever write bits are suitable. (chmod 777 is generally a terrible idea, and you shouldn't do that, but you do you.)

If you're using POSIX ACL then everything gets even more complicated… good luck, have fun! (Yes, there was a "cron job" to fix those, too. I love the smell of burn-out in the morning.)

At a $PREVIOUS_JOB I ended up with essentially a cron job (it was actually an Ansible playbook) that would periodically correct the permissions on a directory tree. I'm pretty sure I gave up and mounted various filesystems with BSD semantics at some point, but still had to run the "cron jobs" because the users sometimes went in and did wacky things. (Legacy system, tradition of full shell access for everyone to do whatever, etc.) However, the details of such a script can be very important, and might trash important permissions if done poorly. If you use find(1), you may need to exclude various areas of the gemini tree, or to be careful about how you change the permissions for directories, and distinctly for files. Start small, use test directories, and test and verify things a lot.