My initial reaction would be that this is probably working as intended, but I'm not really sure what the privacy model for tool labs is.

Some shared hosting environments do remove or alter tools like last, w, ps, and others that could leak sensitive or semi-sensitive information about other users and processes on the host. To my knowledge, Tool Labs/Toolforge has ever done this. I would be surprised to find out that Toolserver did it either. The information is not made available to the general public. This information is only disclosed to other Toolforge project members.

I think we can probably make this more obvious somewhere in the signup process and/or the on-wiki help.

Wouldn't the idea to remove those options also be up for discussion? There really is absolutely no need for "last" and probably the other commands to be used by "regular users". Toolforge/Labs access is not too hard to get, so anyone could "easily" get access to the sensitive/semi-sensitive information.

This probably needs some more serious discussion about the nature of tenants within Toolforge. Offhand we could set perms on utilities of this kind that do not allow everyone to run them, but roots/admins obviously have need. But their is a long tail of information available about Tool owners to other Tool owners within the ecosystem and I'm not sure our comfort level with that has ever been well defined.

In T172650#3507552, @chasemp wrote:

But their is a long tail of information available about Tool owners to other Tool owners within the ecosystem and I'm not sure our comfort level with that has ever been well defined.

The long tail is really my main concern. If we state that cross user information disclosure should not happen I'm afraid that we will either have to shutdown Toolforge or block significant portions of functionality that current project members use. Using a per-user chroot would certainly break many Toolforge workflows. Finding and removing/chmod'ing all of the things that users chould use to find information on other users and processes without chroot protections seems like a never ending game of whack-a-mole. The environment provides compilers and interpreted languages with easy access to system level apis, so merely chmoding standard system utilities will not be enough to block all cross-process information disclosure.

The original report is about IP address disclosure. I really think the answer to that concern is disclosing that this is a possibility and that individuals who are concerned that their IP address remain undisclosed should either not participate in the Toolforge project as maintainers or take other actions such as the use of TOR or an anonymizing proxy when connecting to Toolforge via ssh.

I wasn't sure if TOR/proxies were permitted while connecting to Toolforge, so if this option is preferred rather than limiting user options, as mentioned above it should be made more clear before registering.

FWIW, I support stating clearly at sign-up time that origin IP addresses are not private when using labs/toolforge. I don't believe we have the resources to fully lockdown all mechanisms of accessing this information, as @bd808 mentions above.

A general notice about the nature of shared platforms that includes the ability for other users to gather connected IP addresses as well as determine status of users and such seems worthwhile.

In T172650#3531682, @chasemp wrote:

I think we should remove the restrictive security ACL here. This is a policy and notification issue rather than a sensitive security issue.

Ok, its public.

who is another such tool IIRC. But I agree we should just make it clearer that such sharing is expected.

It's not restricted to toolforge users, since you can do that on bastions as well.

Maybe we could consider some extra hop box that only allows normal users to
run SSH, and nothing else?

That would work on bastions I guess, but for toolforge bastions there are some commands more that are needed.

In T172650#3532217, @Krenair wrote:

Maybe we could consider some extra hop box that only allows normal users to
run SSH, and nothing else?

This could be worth forking another task to discuss, but even if we found that this was greatly desired it would probably end up being low priority to implement. As @Luke081515 mentions this would be more likely to be workable for the normal Cloud VPS bastions than for the Toolforge bastions which really are not bastions in any traditional sense and instead are deployment and interactive shell hosts.

There are some (undocumented?) ideas about building a new interactive shell solution for Toolforge that could make isolation between users better not only for privacy but also for resource limit enforcement. That project is not on any concrete implementation timeline yet though.