Skip to content

Permissions in std::tempfile::mkdtemp #2349

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
catamorphism opened this issue May 3, 2012 · 3 comments
Closed

Permissions in std::tempfile::mkdtemp #2349

catamorphism opened this issue May 3, 2012 · 3 comments

Comments

@catamorphism
Copy link
Contributor

There's a comment in std::tempfile::mkdtemp that says "FIXME: u+rwx". I assume the idea here is to set the r, w and x bits for U to 1 and leave other bits unchanged from the default, rather than setting the permissions for the new directory to a fixed bit pattern. But I don't really know the details of how permissions bits work, so I'm filing this.

@killerswan
Copy link
Contributor

Hex 1c0 is octal 700 (decimal 448), which sets the permission to rwx------.

We may just want to set it to rwxrwxrwx (octal 777, decimal 484) and let the system default reduce that to whatever it wants, e.g., rwxrw-rw-, but I'm not entirely sure if it would bitwise and with the default like I expect, or just overwrite it.

@thestinger
Copy link
Contributor

I think this should definitely use 700 like the POSIX mkdtemp, otherwise it's not usable for safely making a temporary work area within a world-writable directory. If it starts off allowing other users to create files in it, you can't then use regular file names inside it without fear of them already being created - possibly as hardlinks. I can't really think of a use case for a randomized directory name which other users have read/write permissions on.

@catamorphism
Copy link
Contributor Author

Fixed in 0a8c039

bors added a commit to rust-lang-ci/rust that referenced this issue Sep 22, 2022
Improve isatty support

Per rust-lang/miri#2292 (comment), this is an attempt at

> do something more clever with Miri's `isatty` shim

Since Unix -> Unix is very simple, I'm starting with a patch that just does that. Happy to augment/rewrite this based on feedback.

The linked file in libtest specifically only supports stdout. If we're doing this to support terminal applications, I think it would be strange to support one but not all 3 of the standard streams.

The `atty` crate contains a bunch of extra logic that libtest does not contain, in order to support MSYS terminals: softprops/atty@db8d55f so I think if we're going to do Windows support, we should probably access all that logic somehow. I think it's pretty clear that the implementation is not going to change, so I think if we want to, pasting the contents of the `atty` crate into Miri is on the table, instead of taking a dependency.
celinval added a commit to celinval/rust-dev that referenced this issue Jun 4, 2024
Update our workspace dependencies by running cargo update.
tshepang added a commit to tshepang/rust that referenced this issue Apr 21, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants