On Tue, 16.03.10 14:52, Juha Tuomala (Juha.Tuomala@xxxxxx) wrote: > > > [Connection] > > SocketDirectory=/tmp/akonadi-myuser/ > > > > into $HOME/.config/akonadi/akonadiserverrc > > How about setting that as default, away from $HOME that can be a NFS > filesystem? I have had problems with it sometimes and that's > probably not a rare case. That is a security hole. Since /tmp knows no further access control an evil user can just create dirs there for each and every single user on the system. Those directories will then be owned by him, and all other users will a) either completely fail to work or b) happily connect to the evil user's services unless the software in question implements two-way credential passing and verification (which I'd bet akonadi doesn't do). So either this is a DoS vulnerability or an even worse security hole. So in short: don't do this. If you safely want to place a socket in /tmp, you need to place it in a random dir, and then symlink (or otherwise refer to it) from $HOME. Or better (as Colin suggested), just use D-Bus to pass around the randomized socket path. (or even better: use the new fd passing in D-Bus so that you don't need to socket path at all) Or even shorter: Unix sucks. At last year's FOSS.in I did a talk about issues like this in Unix and how to work around them in application and how incredibly hard it is to get this right. One of those days I hope to find the time to write a blog story about this. I personally believe introducing a per-user /var/run (maybe as /var/run/users/$USER which is created at login time) is cleanest way to fix all of this. > I can't imagine what harm that would cause to default under /tmp? It's a shared namespace. As such it is a major source of vulnerabitilities, especially if the developers didn't have this particular use in mind. Lennart -- Lennart Poettering Red Hat, Inc. lennart [at] poettering [dot] net http://0pointer.net/lennart/ GnuPG 0x1A015CC4 -- devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxxx https://admin.fedoraproject.org/mailman/listinfo/devel
