[Suggestion] Delete mount directory after unmounting

[Opening-Button-8988]

[Suggestion] Delete mount directory after unmounting

[smessmer]

If you set the correct permissions on /tmp/something , then it shouldn't be any different from other locations on your file system. There is no reason to colocate it with the basedir.

[smessmer]

Hi, thanks for reaching out. The behavior of `cryfs-unmount` is similar to the linux `unmount` tool which doesn't delete the directory either. But I'd be willing to review and accept a PR that adds the feature you're proposing. Until then, I recommend using `rmdir` instead of `rm -r` since `rmdir` only deletes empty directories and will fail if they are not empty.

…

On May 23, 2023 04:39:09 Opening-Button-8988 ***@***.***> wrote: I would like to see an optional argument added to the cryfs-unmount command that removes the directory after successfully unmounting. Since the mountdir is really just a symbolic link to the virtual filesystem, having remnant mountdir's, creates some mess and causes some confusion particularly if you can't remember whether it was unmounted or not. And perhaps most importantly, at least personally, I get (relatively) nervous when I need to run rm -r for obvious reasons. — Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[Opening-Button-8988]

@smessmer Thanks for your response, and apologies for the delay in mine.

Thanks for that suggestion, I'll use rmdir instead from now on.

Is it safe to mount to /tmp/?

As I'm not a developer I wouldn't know how to conduct a PR so I can't be of help in that regard. I'll close this issue if that's okay.

[smessmer]

Is it safe to mount to /tmp/?

The /tmp directory is often world-read/writeable, so any other program on your computer can read and write to it and expects to be able to do so or may crash. By default, CryFS only allows access to the user who actually mounted it so if you actually want other users or processes to access it (which for /tmp sounds like you may want to), you could look at the -o allow_root -o allow_other command line parameters. There's also the question whether other programs can handle you mounting or unmounting the file system after they're already running and have written things to it, you may want to make sure it gets mounted at system startup and stays mounted until shutdown.

Or did you mean mounting to /tmp/something and not to /tmp itself? I don't see any issues with that

[Opening-Button-8988]

@smessmer The reason I asked was because I figured /tmp/ was appropriate to mount temporary files/filesystems because when it's unmounted and the system restarts, the contents get flushed, which is convenient. I don't have any other users on my system and I don't plan to. I also have a high security requirement, so from what I gather it sounds like mounting to /tmp/ is not a good idea. However, you have said /tmp/something is different; does this mean /tmp/ can be read by any program, while /tmp/something cannot? If there's no security/privacy risk doing that, then I suppose I'll do that. The only reason is to have the empty mountpoints disposed of more easily. It just saves me having to do it manually.

For maximum security, does it make more sense to mount on the same disk and directory as the basedir? It seems that way to me. Perhaps it would have lower system overhead as well?