wezterm/umask/Cargo.toml

[package]
name = "umask"
version = "0.1.0"
authors = ["Wez Furlong <wez@wezfurlong.org>"]
edition = "2018"

# See more keys and their definitions at https://doc.rust-lang.org/cargo/reference/manifest.html

[dependencies]
lazy_static = "1.4"
libc = "0.2"
Move server to its own wezterm-mux-server binary 2020-10-03 09:35:18 +03:00			`[package]`
			`name = "umask"`
			`version = "0.1.0"`
			`authors = ["Wez Furlong <wez@wezfurlong.org>"]`
			`edition = "2018"`

			`# See more keys and their definitions at https://doc.rust-lang.org/cargo/reference/manifest.html`

			`[dependencies]`
Take care to restore the original umask wezterm sets a more restrictive umask (`0o077`) by default so that any files that it creates (eg: unix domain socket, log files) are more secure by default. However, some environments rely on the more general default of (`0o022`) without checking that it is set. This matters because programs spawned by wezterm inherit its more restricted umask. I hadn't noticed this because I've had `umask 022` in my shell RC files since sometime in the 1990's. This commit adds some plumbing to the pty layer to specify an optional umask for the child process, and some more to our umask saver helper so that any thread can determine the saved umask without needing a reference to the saver itself, which may be in a different crate. The logic in the config crate has been adjusted to connect the saved value to the default command builder arguments. The net result of this is that running `wezterm -n start bash -- --norc` and typing `umask` in the resultant window now prints `0022`. refs: #416 2021-01-07 20:14:51 +03:00			`lazy_static = "1.4"`
Move server to its own wezterm-mux-server binary 2020-10-03 09:35:18 +03:00			`libc = "0.2"`