Ticket #1466 (reopened defect)

Opened 15 years ago

Last modified 13 years ago

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

Reported by: narcan Owned by:
Priority: minor Milestone: Future Releases
Component: mc-core Version: 4.6.2
Keywords: Cc:
Blocked By: Blocking: #329
Branch state: no branch Votes for changeset:

Description

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

Change History

comment:1 Changed 15 years ago by iNode

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

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.

comment:2 Changed 15 years ago by iNode

  • Status changed from closed to reopened
  • Resolution duplicate deleted

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

comment:3 Changed 15 years ago by narcan

  • 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

comment:4 Changed 15 years ago by 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.

comment:5 Changed 15 years ago by 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.

comment:6 Changed 15 years ago by 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?

comment:7 Changed 15 years ago by 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?

comment:8 Changed 15 years ago by 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.

comment:9 Changed 15 years ago by 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.

comment:10 Changed 15 years ago by 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?

comment:11 Changed 15 years ago by 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.

comment:12 Changed 15 years ago by iNode

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

comment:13 Changed 15 years ago by iNode

  • Blocking 329 added

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

comment:14 Changed 13 years ago by andrew_b

  • Branch state set to no branch
  • Milestone changed from 4.7 to Future Releases
Note: See TracTickets for help on using tickets.