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

[mc-butler]

Important

This issue was migrated from Trac:

Origin	https://midnight-commander.org/ticket/1466
Reporter	narcan (debian@…-briand.fr)

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

[mc-butler]

Changed by iNode (@iNode) on Aug 5, 2009 at 13:47 UTC (comment 1)

• Status changed from new to closed
• Resolution set to duplicate

Please use search before report bugs, this report is double for
#32.

Please report in #32 more details to reproduce bug.

I close this ticket as double.

[mc-butler]

Changed by iNode (@iNode) on Aug 5, 2009 at 13:57 UTC (comment 2)

• Status changed from closed to reopened
• Resolution duplicate deleted

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

[mc-butler]

Changed by narcan (debian@…-briand.fr) on Aug 5, 2009 at 14:03 UTC (comment 3)

• Summary changed from leaves temporary directories behind on exit: /tmp/mc-$USER/ to leaves EMPTY temporary directories behind on exit: /tmp/mc-$USER/

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

[mc-butler]

Changed by iNode (@iNode) on Aug 5, 2009 at 14:05 UTC (comment 4)

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.

[mc-butler]

Changed by ossi (@ossilator) on Aug 5, 2009 at 14:46 UTC (comment 5)

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.

[mc-butler]

Changed by iNode (@iNode) on Aug 5, 2009 at 15:34 UTC (comment 6)

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?

[mc-butler]

Changed by ossi (@ossilator) on Aug 5, 2009 at 17:14 UTC (comment 7)

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?

[mc-butler]

Changed by iNode (@iNode) on Aug 5, 2009 at 19:54 UTC (comment 8)

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.

[mc-butler]

Changed by ossi (@ossilator) on Aug 5, 2009 at 21:48 UTC (comment 9)

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.

[mc-butler]

Changed by iNode (@iNode) on Aug 6, 2009 at 6:15 UTC (comment 10)

$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?

[mc-butler]

Changed by ossi (@ossilator) on Aug 6, 2009 at 10:09 UTC (comment 11)

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

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

[mc-butler]

Changed by iNode (@iNode) on Sep 12, 2009 at 9:09 UTC (comment 12)

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

[mc-butler]

Changed by iNode (@iNode) on Sep 12, 2009 at 9:09 UTC

• Blocking set to #329

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

[mc-butler]

Changed by andrew_b (@aborodin) on Oct 29, 2011 at 16:56 UTC (comment 14)

• Milestone changed from 4.7 to Future Releases
• Branch state set to no branch

[mc-butler]

Changed by zaytsev (@zyv) on Jan 10, 2025 at 17:31 UTC (comment 15)

• Resolution set to worksforme
• Blocking #329 deleted
• Status changed from reopened to closed
• Milestone Future Releases deleted

System changed in #4535 - this resolves the original Debian bug.