Aggregate "magic directories" under ~/public (or something equivalent)
#144
No Assignees
Notifications
Due Date
No due date set.
Blocks
#115 Host OpenPGP server or WKD for users
Drift/issues
#132 User sourced stickers and emoticons
Drift/issues
Reference: Drift/issues#144
Reference in New Issue
Block a user
No description provided.
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
We have a set of magic directories that lets you create different types of content that gets picked up by our systems and hosted in different ways. Currently, these are:
~/web-docs- user web pages. These have been here sinc the dawn of time. Hosted on tom.~/public_gopher- gopher holes. These are really new. Hosted on isvegg.~/pvv-photos- gallery photos. These are also relatively new. rsynced from microbel to bekkalokk, and hosted there.These are all located in the toplevel of every users home directory, and it will become quite the mess when we introduce even more (I already consider it a mess). We should probably aggregate them all under a common directory, where all of the magic stuff goes.
In order to not cause too much breakage, we should leave symlinks. Especially for web-docs, since it's so old. We might consider not doing it for the newer ones.
~/web-docshas been here forever, and I expect people to have these files linked all over the place, scripts with hard-coded paths, scripts that automatically put things in~/web-docs, etc.The other ones are quite new and flexible, and I support just moving them to a new location, like under a common
~/public.I think we can just do this without a lot of planning or notice, as they probably won't break anything (TM), as long as we update the appropriate documentation.
At the same time, I would maybe like to add some placeholder directories and README.txt into /etc/skel, to prepare this for new users.
A longstanding issue with the current implementation is that the web server needs
+xon the entire home directory in order to read~/web-docs. Whatstud.ntnu.nodoes to avoid granting this access is to place the web files completely outside the home directory, and make a symlink inside the home directory for backwards compatibility. This allows the user to not let anything else access their home directory, which significantly reduces the splash zone if someone exploits the web server. I would suggest a similar approach if we're going to make changes to this.The way I see it, there are currently two implementation concerns:
Could we find a solution that solves both? Could we create a sort of virtual space for the webserver, where root (or systemd) bindmounts the relevant directories so that anything outside is completely unaddressable by path? Or are there any performance concerns with doing this on top of NFS?
Alternatively, we could set up an OpenBSD box to host user websites, and find a webserver that would let us make use of
unveil(2)from my experience with bubblewrap: nfs and namespace bind mounts rarely play well together. This is a shortcoming in the kernel
Two users already exist with
~/public: oyvinlek and andersja. Should we ask them before we just take over this directory name to have a sideeffect? I think oyvinlek's contents of this directory is the most likely to clash with the names of the magic dirs. They also seem to be an active user of our systems.~/pvv-public?No, we talked with oyvinlek and he changed his dirname. I think the coast is clear
FTR, microbel's photo gallery script already handles
~/public/pvv-photos