Re: Issues with /tmp/mc-$USER directory
On Wed, 25 Dec 2002, Koblinger Egmont wrote: [..] temporary directory should be created by mkdtemp(), it should be removed at exit, O_EXCL should IMHO be removed when opening the -P file, the wrapper script should use a file under the user's home, or a file created by the mktemp command. Next close thing .. Sometimes $TMPDIR is assigned to ~/tmp or smething similar and sometimes volumen with /home is mounted as noexec and this breaks many mc functiomalities like cd arch_file. It will be good also clean this patr too by not direct run generated in $TMPDIR script and run this script as /bin/sh parameter. kloczek -- --- *Ludzie nie maj problemw, tylko sobie sami je stwarzaj* --- Tomasz Koczko, sys adm @zie.pg.gda.pl|*e-mail: [EMAIL PROTECTED]* ___ Mc-devel mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/mc-devel
Re: Issues with /tmp/mc-$USER directory
On Sun, 29 Dec 2002 00:15:30 +0100 (CET) Tomasz Koczko [EMAIL PROTECTED] wrote: Next close thing .. Sometimes $TMPDIR is assigned to ~/tmp or smething similar and sometimes volumen with /home is mounted as noexec and this breaks many mc functiomalities like cd arch_file. But you can always redefine TMPDIR, where's the problem? Or do you want mc to check for such cases? IMHO it's overkill. Regards, Nerijus ___ Mc-devel mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/mc-devel
Re: Issues with /tmp/mc-$USER directory
On Sun, 29 Dec 2002, Nerijus Baliunas wrote: On Sun, 29 Dec 2002 00:15:30 +0100 (CET) Tomasz Koczko [EMAIL PROTECTED] wrote: Next close thing .. Sometimes $TMPDIR is assigned to ~/tmp or smething similar and sometimes volumen with /home is mounted as noexec and this breaks many mc functiomalities like cd arch_file. But you can always redefine TMPDIR, where's the problem? Or do you want mc to check for such cases? IMHO it's overkill. Problem is in mc. It will be good if mc will do not depend on exec/noexec volumen where poinst $TMPDIR wnd this can be easyly solved by not direct executing generated by mc in $TMPDIR scrips .. and this is not overkill. kloczek -- --- *Ludzie nie maj problemw, tylko sobie sami je stwarzaj* --- Tomasz Koczko, sys adm @zie.pg.gda.pl|*e-mail: [EMAIL PROTECTED]* ___ Mc-devel mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/mc-devel
Re: Issues with /tmp/mc-$USER directory
Hi! I don't want to delete the directory on exit because there are many reasons why mc can exit (including crash and killing it when rebooting the system). Considering that the temporary directory may have huge files in it, I would prefer to have a fixed name for it, so that it could be easily cleaned up by scripts if mc exists without cleaning some files. 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. Using fix file names under /tmp is impossible without risking security. You can use fix file names under your home, or a unique non-existant filename under /tmp. However, you can still use filenames that match the pattern /tmp/mc-$USER-* or similar, which might help cleanup scripts a lot. It is also possible to check whether /tmp/mc-$USER exists (and try to create it and see if it's successful) and use it if it's yours, and only fallback to some other ugly name if it is stolen by someone else. mkdtemp would be great if it was more portable. info libc says it comes from OpenBSD, so I don't think you can find mkdtemp on every UNIX. 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 :)) 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 writeable /tmp. Am I 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? bye, Egmont ___ Mc-devel mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/mc-devel
Re: Issues with /tmp/mc-$USER directory
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 ___ Mc-devel mailing list [EMAIL PROTECTED] http://mail.gnome.org/mailman/listinfo/mc-devel
