[Users] [Bug 2828] Use MD5 digest for socket name

[Ricardo Mones]

On Thu, Nov 29, 2012 at 11:02:29AM -0500, ratinox at gweep.net wrote:
> On Thu, 29 Nov 2012 09:33:59 +0100
> Ricardo Mones <ricardo at mones.org> wrote:
> 
> >   That's not what was being claimed... but yes, it is. It could
> > also be seen as a nice local DoS attack, because is trivial to create
> > the same file as any other user in /tmp (home config dirs are easily
> > guessable). So I think /tmp is not the right place for this.
> 
> /tmp really is the best place to put the lock if you want to have
> multiple UIDs sharing a single configuration directory. All UIDs
> sharing the configuration must be able to see the lock socket. If the
> lock is unique to one UID then the other UID will not see it. This
> would permit multiple simultaneous access to a single configuration.
> This is not desired and is therefore a bug.

  The own configuration directory serves the same purpose, as both uids
have access to it.
 
> /tmp is a good place to put the lock anyway. Locks need to be visible
> to all processes that might try to claim the resources. Privatizing a
> lock makes it impossible for other processes to see it.
> 
> Yes, it's vulnerable to a local denial of service. So is using
> /tmp/claws-mail-${UID} as the lock socket name.

  The config dir mitigates this only to uids which have access not to all
system uids, and still is visible to all claws-mail processes which could
use such resource.

> Old, unused sockets aren't an issue. The periodic /tmp cleaner will
> reap them.

  That's lost, but that already happened with --alternate-config-dir,
so I think that's bearable.

> >   D'oh! So you claim A, when shown A is false you jump the it's a
> > feature wagon running on the opposite direction... Amazing :)
> 
> I can't help it if you misinterpreted my writing that "two UIDs could
> share a configuration directory" as "two UIDs could share a
> configuration directory simultaneously".

  Yep, that could be.

> >   Don't be shy, very likely nobody else is going to do it ;)
> 
> Nope. It's impossible to do reliably. Look at the BUGS section of the
> realpath(3) man page.

  I see, but like many other things it doesn't need to be perfect: just
to work on the 99.99% sane cases and fail miserably on the other 0.01%.

  regards,
-- 
  Ricardo Mones 
  ~
  The three principal virtues of a programmer are Laziness, 
  Impatience, and Hubris.                                    man perl

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://lists.claws-mail.org/pipermail/users/attachments/20121129/ce5b0fd8/attachment.sig>