The permissive mask is purposeful. We want most things to be readable by others normally.

Perhaps I was too fast in declaring the current umask "too open", and I see the point in having the greatest possible openness and transparency.

At the same time, personally I was surprised to find that I could read files from other tools. When I ran become mytool, I always naively assumed that I could safely store things in that directory that I wanted only the tool maintainers to see, so not just the source code but potentially also various kind of secrets.

If we want to keep the current umask, that's fine with me, but I would suggest we add a banner in the console (that could be shown after you ssh to the bastion, or after you run become mytool) to remember you that any file you create there will be readable by default by any other user of Toolforge. This help page also seems to suggest that only files in /data/project/shared are readable "by all Toolforge tools and users". I would clarify in the wiki that also applies to the files in /data/project/mytool.

Personally, I would be more comfortable with a model where only the tool maintainers can access the tool home directory, and there is a separate shared directory (or maybe Swift?) if you want to explicitly share something with other users. But it might just be that I'm used to interacting with commercial platforms where that is the default, so I very much welcome a conversation on the pros and cons of both approaches.

https://wikitech.wikimedia.org/wiki/Help:Toolforge/Quickstart#File_permissions

IMO the permissive umask is pretty important in supporting the right to fork in a soft manner and increases the sustainability of tools when more people can peek at them.

There are of course, plenty of people who miss this and end up leaving credentials world-readable (just look for the tens of security tasks filed by @LucasWerkmeister on this topic). But tools don't really have *that* sensitive data/credentials in the first place (and the few tools that do have pretty careful maintainers or are isolated through separate Cloud VPS projects) that in practice the current balance of openness at the cost of a little bit of security seems reasonable to me.

Thanks @bd808 and @Legoktm for giving me more context. Would you object to the addition of a message when running become mytool to remind users of the default settings? I added a possible draft below. If you think that is too intrusive, and I'm the only one who wants this, I'm happy to close this ticket as "Declined".

fnegri@tools-sgebastion-10:~$ become mytool
------------
You are now acting as "mytool". Remember that files you add to your home directory (/data/project/mytool)
by default can be read by any other Toolforge user. If you need to create a file containing sensitive
information (credentials, etc.) please read https://wikitech.wikimedia.org/wiki/Help:Toolforge/Quickstart#File_permissions
------------
tools.mytool@tools-sgebastion-10:~$

I have updated https://wikitech.wikimedia.org/wiki/Help:Toolforge/Developing_successful_tools#Sharing_files_via_NFS to clarify that files in /data/project/<tool> are readable by other tools, in a similar way to files placed in /data/project/shared.

I generally agree with @bd808 and @Legoktm that changing the umask would be overkill. Adding a message to become sounds like a good idea to me, especially for new users, though I expect more experienced users will eventually want a way to silence this warning, via an env var or ~/.config/become config file or whatever.

The current 022 default umask appears to be implemented in /etc/login.defs and unchanged from the upstream Debian default configuration. This means that it applies to all users, not just the tool account users that are switched to via our become script.

$ grep -i umask /etc/login.defs
#       UMASK           Default "umask" value.
# UMASK is the default umask value for pam_umask and is used by
# 022 is the "historical" value in Debian for UMASK
# If USERGROUPS_ENAB is set to "yes", that will modify this UMASK default value
UMASK           022
# Other former uses of this variable such as setting the umask when

To me this makes a specific warning added to become feel like noise. Maybe adding something to the motd would be more reasonable if folks really do believe that a) this is worth an explicit warning and b) that anyone actually reads the motd or other login banners.

The permissions of a tool's home directory /data/project/<tool> are 755, so anyone can traverse it.

This is actually the bit that is most likely to be the "surprise" and not the umask value.

This is actually the bit that is most likely to be the "surprise" and not the umask value.

I agree, the umask is not the surprising thing here. I have updated the title accordingly, feel free to rephrase further.

While improving documentation is always great and appreciated, my hopefully not-too-cynical take is that any nagging in MOTD or prompts from become will just be ignored by most users. I'd rather see time/effort invested in proper secrets management, so we can guide people into systems that are properly set up to protect credentials, etc.