Re: Issues with /tmp/mc-$USER directory

[Pavel Roskin <proski gnu org>]

Hello!

> Removal could only happen when mc exits cleanly. E.g. the removal of that
> directory tree could be executed when F10 is pressed (and confirmed). This
> way it isn't removed when mc crashes or is killed.

It's acceptable, but I'd prefer to try the fixed directory name first.
KDE and ORBit use fixed names, so it should be possible.  I don't have a
strong opinion about it.  I'd like to hear from other developers.

If we want to try both, the logic should be:

1) Check that /tmp/mc-$USER is ours.  I think if I do stat() and it says
that I'm the owner, no adversary will be able to replace the directory.
If /tmp/mc-$USER is ours, set proper permissions (700) on it if necessary
and use it.  Note that the files inside that directory still have random
names.

2) If that fails, warn the user and create a directory under /tmp with a
random name e.g. /tmp/mc-$USER-$RANDOM.  If that works, schedule the
directory for removal using g_atexit (portable atexit from glib) and use
the directory.

3) If that fails, warn the user, set temporary directory to NULL and
continue, but deny any requests to create temporary files.

> Maybe some configure-check for whether it is available... Sorry, I'm not
> familiar with any Unices other than Linux. Alternatively an own
> implementation would be good which creates random filenames and tries to
> open them with O_EXCL. If it succeeds, that file/dir is yours. Maybe take
> a look at the glibc sources how these calls are implemented there :))

Actually, mc_mkstemps from util.c already has a random name generator.

> > It is important to have a fallback for the case if something is wrong with
> > the temporary directory.  Midnight Commander should be useful even on
> > systems with all filesystems mounted read-only.
>
> But I guess we only expect the very basic features of mc to work, not the
> virtual file system, nor the -P option when the system doesn't even have a
> writable /tmp. Am I right?

Right.

> > Any help with this fix will be appreciated.  All other issues have been
> > addressed.  As soon as this issue is fixed, 4.6.0-pre2 will be released.
>
> Shall I write patches and send them to you to see if you like them? Or
> should I just try to figure out what should be done and leave the
> implementation to you?

It's more important that we decide what to do.  Still, if you write a
patch, it will be appreciated.

-- 
Regards,
Pavel Roskin