[Users] [Bug 2828] Use MD5 digest for socket name
ricardo at mones.org
Sun Dec 2 03:48:26 CET 2012
On Sat, 1 Dec 2012 23:13:23 +0100
Holger Berndt <berndth at gmx.de> wrote:
> On Sa, 01.12.2012 13:21, Colin Leroy wrote:
> >> But anyways, it's a matter of preference what's more valuable: Safety
> >> against different uids trying to mess with the same config dir at the
> >> same time, or DoS prevention. Personally, I lean towards the second.
> >Different UIDs should not be messing with the same config dir anyway.
> Agreed. I don't see the "different uids at the same time" usecase as an
> interesting one either, as I wrote above.
Indeed, I thought of it as a possibility for sharing read-only config dirs
(and mail relative to users $HOME), but now I agree it's a bad idea™ for
most of the cases, or at least until runtime data is separated from config.
> >The UID in the socket name is there just to allow different users run
> >different instances of Claws Mail at the same time, not to prevent DoS
> >or anything.
> Of course it's not there to prevent DoS. But - and this is the problem
> Mones spotted - the way it's implemented, it makes Claws Mail vulnerable
> for local DoS attacks. It's trivialy easy to block Claws Mail for all
> users on a shared machine (just create a bunch of /tmp/claws-mail-1234
> files). And, if the "different uids" usecase is not interesting
> anyways, on which we seem to agree, it's making Claws Mail vulnerable
> for no benefit whatsoever.
> This is bad design, and it doesn't have anything to do with
> alternate-config-dir. It just poped up by coincidence during that topic.
Right, we had the problem before.
> The solution would be to ...
> >Also, I feel we're getting a little bit carried away there with
> >XDG_RUNTIME_DIR and everything. Supporting XDG would be great, but we
> >don't, right now.
> ... create your socket in a user-specific place instead of public /tmp.
> Now, you can either make up a directory name, or use a specified and
> configured one that's already there. By coincidence, there indeed is
> already a spec for exactly this usecase, it's followed on many modern
> machines, and it happens to be called XDG_RUNTIME_DIR. There's nothing
> magic, really.
> And you don't need to follow XDG either. On the contrary, if that
> variable is set, it help you in so far as it guarantees that it's gonna
> work (you're guaranteed to be able to create unix domain sockets there,
> unlike in random directories that you make up, which could themselves
> be on FAT or whatever).
The public directory can still be used as long as the names created cannot
be easily guessable. The MD5 makes it a bit more difficult. Using content
of XDG_RUNTIME_DIR could be interesting, yes. But on machines where it's
not defined we still need some default, because making it required doesn't
> >Maybe we can start caring about XDG_RUNTIME_DIR when we'll have
> >migrated our config dir to XDG_CONDIR_DIR and imap caches to
> General XDG conformity is a completely unrelated topic.
> >In the meantime I couldn't care less if the socket name is rendered
> >unique using UID, config-dir-name hash, md5sum of the user's full name
> >appended to the computer domain name or whatever.
> Now you're talking about a feature (being able to put config dir on FAT
> or similarly limited filesystems). That's, as I said above, not really
> related to above notes. It could be done either way (putting it
> into /tmp, or putting it into /run/user/foo would work equally well
> >> don't remove uid from socket name, just add the MD5, otherwise two
> >>different users could clash using the same dir.
> Weird quoting. I didn't write that.
Nope, that was me :)
> >That's misguided, we sure as hell don't want two users running two
> >instances of Claws Mail, writing UIDL files, preferences and IMAP cache
> >files in the same configuration directory.
> >Having the unicity on config dirs only is actually better than on UID +
> >config dir. Of course the hash has to be on the absolute path.
> >Or am I missing something there?
> No, you're not. That's exactly what I said ("But that's actually a
You have the capacity to learn from mistakes. You'll learn a lot
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 198 bytes
Desc: not available
More information about the Users