leaves EMPTY temporary directories behind on exit: /tmp/mc-$USER/

[narcan]

Hello,

"mc doesn't remove its temporary directory on exit, it
leaves /tmp/mc-$USER/ behind"

This is annoying on servers with a big uptime and several users accounts.
Maybe add an option to choose between "remove" or "not remove" temp files on exit?

This is the original bug report:
​http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=504151

Thank you

Denis Briand

[iNode]

Please use search before report bugs, this report is double for
​http://www.midnight-commander.org/ticket/32.

Please report in #32 more details to reproduce bug.

I close this ticket as double.

[iNode]

Oh, this not the same, but related. Sorry.

[narcan]

Oops I forget the "EMPTY" word in the subject.
Yes is not the same.
I talk about empty directories not files into it

Thanks

Denis

[iNode]

I'll propose use $TMP/mc-$PID-${MKTMPDIR} and clean-up on mc exit for each users mc-$PID-*.

${MKTMPDIR} suiffix need to avoid

    mkdir -p /tmp/mc-paul
    chown michelle: /tmp/mc-paul
    chmod 700 /tmp/mc-paul

    and now paul try to use mc...

$PID - to check running mc instances.

[ossi]

making process-specific directories just increases the clutter and leaves even more garbage behind when instances crash.

i for one would simply reject the request. the system is responsible for cleaning up /tmp on reboot, and in between a busy system's /tmp is a complete mess anyway.

as for the predictable name DoS vulnerability: kde has a rather elegant solution for that: applications use ~/.kde/tmp-$HOSTNAME, which itself is a symlink to /tmp/kde-$USER - unless that directory is owned by someone else, in which case /tmp/kde-$USER-$MKTMPDIR is used. point is that there is still a stable reference, so /tmp doesn't get utterly polluted just because somebody tried a lame attack.

[iNode]

First, each mc exit should clean all garbage. Second, mc should not crash, but if it crash
other mc instance clean all garbage at exit.

There is long time run machines (like servers, you know), so no reboot and no cleanup.

If we can easy prevent this kind of "attack" why don't do it?

[ossi]

of course mc should clean up, but that's a bit hard given the shared temp subdir.
and separate subdirs *will* increase clutter. for one, mc never crashing is wishful thinking. second, have you ensured that SIGHUP is properly handled in every case? and even if mc never crashes, i would find 10 *current* mc-ossi-* directories in /tmp a bit ... excessive.

i wonder, why does mc create an own temp subdir at all? presumably to provide unsafely written vfs scripts a safe environment?

[iNode]

i would find 10 *current* mc-ossi-* directories in /tmp

You must has 10 crashes consecutive for get it.
They will be deleted at exit any other mc session of this user.

[ossi]

you proposed mc-$PID-${MKTMPDIR} (ok, so there is no $USER part in it ... whatever). that means that the mcs in my six xterms and four console logins will produce ten independent *current* directories.

[iNode]

$USER part is pid of directory owner.

Yes, 10 mc session will produce 10 temp directories, as
it do for 10 different user sessions now, as each Xorg sessiod
produce socket for interaction, as flash plugin in your
browser produce one temporarily file per flash, and so on...

What's the problem?
Do you propose any other variants to solve "attack" to mc temp directory?

[ossi]

i think i just have a personal dislike against many directories in /tmp. ;)

i already pointed to a solution for the name clash attack.

[iNode]

We also should respect $TMP or $TEMP variables if there is one or use /tmp otherwise.
It's also prevents described "attack".

[iNode]

(In #329) Should be solved in #1466.