spawned processes have umask = 0077

[zeusintuivo]

Describe the bug

using a mac. actually I could replicate in two macs. while using wezterm, all the permissions for file and folders got lost to user 501. and permissions blocked to rw- --- --- so, it breaks the entire mac systems.

Environment (please complete the following information):

• OS:macOS Catalina and BigSur
• Version: WezTerm-macos-20201101-103216-403d002d

To Reproduce

Steps to reproduce the behavior.

open wezterm
start installing brew or mysql or anything, and watch your system become unstable
check the rights of /usr/local/Cellar for example or anything you installed would be ruined, blocked or not accessible

Configuration

no file

Expected behavior

Expected to be able to use it normally with no repercutions

Screenshots

NA

Session Recording

NA

Additional context

@wez @dsp @misaelnieto

[wez]

I suspect that you might have an issue with your umask in your shell configuration.
Can you try to minimize what you're running?

For example; try the following and share the output:

• start wezterm
• run umask
• touch /tmp/a-file
• ls -l /tmp/a-file

Compare that with eg: Terminal.app

wezterm doesn't know anything about brew or /usr/local/Cellar and doesn't have code to go and actively change the permissions across the the system, and can't hook into what brew is doing, so it seems unlikely that it is literally doing what you've described in this issue.

[zeusintuivo]

I am aware the wezterm does not know anything about brew. But something is off. I already killed two MAC laptops, I started to set up. Then I added wezterm, and oops. All chaos. I had to go to recovery mode and fix the file permissions manually. Both had the same issues. I find that terribly bad. Unless I could be wrong and it was brew. But wait a minute I also downloaded MySQL from website install, not the brew version, and it also managed to do something to the permissions, of those folders. Not the installers, but when I ran commands from the terminal to setup MySQL setup, So right now, my suspicion is wezterm. My second suspicions could be a new shitty macOS issue with Catalina and Big Sur, where macOS systems a becoming more and more unstable with every new macOS release.

[wez]

At this point there's not much for me to go on. I asked for you to run some basic commands to help prove/disprove the most likely source of permissions that anyone using a shell in a terminal is likely to face; until I see that I have no concrete information on what is happening. Beyond that, the way that terminals and shells work, it is "impossible" for there to be any additional side effects bleeding down from the terminal emulator after the shell is started.

From what you've described, I would suspect that something went wrong with installing some of the other software you mentioned: that seems like a much more likely candidate, especially if you are using sudo or similar to elevate the privileges of the commands that are being run.

Please keep in mind that none of the other users of wezterm have run into behavior that is similar to what you have described.

[MuhammedZakir]

When executing umask, I get 077 for wezterm and 022 for all other terminals (Terminal.app, iTerm2, Kitty & Alacritty).

Edit: for touch /tmp/a-file, ls -l /tmp/a-file: -rw------- for wezterm and -rw-r--r-- for others.

[zeusintuivo]

Sorry, it took me long to respond, but I was busy fixing those laptops.
In the mac I got the same problem as result bad result as stated by @MuhammedZakir
(Terminal.app, iTerm2, Kitty & Alacritty)

touch /tmp/a-file, ls -l /tmp/a-file: == -rw-r--r--

(wezterm)
touch /tmp/a-file, ls -l /tmp/a-file: == -rw-------

In Linux Fedora, there seems to no issue.
(Gnome-Terminal, Guake, Terminator)

touch /tmp/a-file, ls -l /tmp/a-file: == -rw-r--r--

(wezterm)
touch /tmp/a-file, ls -l /tmp/a-file: == -rw-r--r--

In conclusion, installing anything in a macOS using from inside wezterm, now, it will mangle the file systems terribly. I had to reset the harddrive and reinstall the entire system in one and the other just the entire /usr had to be recreated mainly.

Could it be a Rust problem ?

[wez]

wezterm sets umask 077 so that unix domain socket(s) used by the multiplexer, and log files are safer, but doesn't restore the prior umask when spawning child commands.

I hadn't noticed this because I've had umask 022 in my shell rc files since sometime in the 1990's because I couldn't trust the default on whatever weird flavor of unix I was running in at the time.

I would recommend that you also put umask 022 in your shell configs to ensure a consistent experience in general.

I've pushed a commit that restores the umask to whatever it was set to by the process that spawned wezterm so that this should be less surprising.

FWIW, if a software installation process is sensitive to umask, I would consider it a bug in the installer; the umask isn't required to have any particular value (if it was, it wouldn't be a feature of unix systems; it would just be hardcoded) and security conscious unix users do often set a more restrictive umask.

[tntljc]

@wez This issue seems reoccur recently?
I'm using wezterm 20220101-133340-7edc5b5a
I killed server and restart wezterm, the umask is 0077:

~$ umask -S
u=rwx,g=,o=

[wez]

@tntljc please file a separate issue and include all of the information requested by the form, thanks!

[github-actions]

I'm going to lock this issue because it has been closed for 30 days ⏳. This helps our maintainers find and focus on the active issues. If you have found a problem that seems similar to this, please open a new issue and complete the issue template so we can capture all the details necessary to investigate further.