Page MenuHomePhabricator

Suggesting addition to tool labs documentation regarding tools that delibrately chmod their tool home dirs o-rx
Open, LowPublic

Description

If others are not able to see the tools home directory, there is technically no way (besides using sudo) to know the tools source code / data / setup, unless the source code is published and the exact steps to duplicate the environment is publicly documented elsewhere, others will not be able to debug what is wrong with a tool if they have issues with it. I suggest that a documentation page like the FAQ could contain something like:

Do not set your tool home directory permissions so that others cannot read it, without documenting the full setup, because:

  • it can be very difficult to ask for all the information required for debugging if you run into issues.
  • no easy way to fork your tool.
  • no transparency / openness; generally against labs ideology.

Unless a tool labs very good reasons to prevent reading every single file/directory in the tool home directory altogether (which I can't think of any), tools may hide individual files/directories in case of secret data.

See T164191#3228024 for one case where a tool chmod their tool dir 770

Related Objects

Event Timeline

Restricted Application added a subscriber: Aklapper. · View Herald Transcript
bd808 triaged this task as Medium priority.May 2 2017, 4:17 PM
bd808 added a project: Documentation.
bd808 moved this task from Triage to Backlog on the Cloud-Services board.

This sounds like a good topic for the Toolforge-standards-committee to look into.

I think users should be free to decide what to do with their directories as long as they don't violate labs ToU. The right to fork policy is not automatic but conditional in that the committee has to approve it, and certainly some of us only use of Labs to run a bot and whose only "original" files are those who ain't included or avalaible to fork or our privacy would be compromised. Given that use, it makes perfect sense to have a directory closed notwithstanding your problem in that if you ever run into problems you cannot be helped so much. But that's the owner's choice. In the case a tool is misbehaving or being harmful, any admin can shut it down and look into it, which are really the people we trust to help mantain Tool Labs run smoothly and that can have access already in a need-to-know basis. Thank you.

our privacy would be compromised.

See ticket description:

Unless a tool labs very good reasons to prevent reading every single file/directory in the tool home directory altogether (which I can't think of any), tools may hide individual files/directories in case of secret data.

There is no problem with chmodding private data (anything privacy/security related) with o-rwx, but there is absolutely no reason I can think of that require the entire tool dir to be read-proof.

certainly some of us only use of Labs to run a bot and whose only "original" files are those who ain't included or avalaible to fork

My interpretation of that policy is that: Tool authors should make it easy for others to fork a tool (adding license/publish code/code-data separation/write documentation). And if the author does not comply with releasing the code when asked by the "forker", they may ask the committee for the code after the committee review it.

All the setups are included in forking, so if the "forker" only got the code but cannot replicate the environment, it still defeats the purpose of the policy. If the tool author chmod their tool dir o-rx without writing the docs on the setup, few can fork it.

if you ever run into problems you cannot be helped so much

Yeah, the docs could be something like: if you don't want help, few will help you.

srodlund changed the task status from Open to Stalled.Aug 29 2018, 10:31 PM
srodlund lowered the priority of this task from Medium to Low.

There still needs to be some resolution about if and what to document before doing so. Resetting priority.

Aklapper changed the task status from Stalled to Open.May 24 2020, 8:01 PM

The previous comments don't explain what/who exactly this task is stalled on ("If a report is waiting for further input (e.g. from its reporter or a third party) and can currently not be acted on"). Hence resetting task status.

(Smallprint, as general orientation for task management: If you wanted to express that nobody is currently working on this task, then the assignee should be removed and/or priority could be lowered instead. If work on this task is blocked by another task, then that other task should be added via Edit Related Tasks...Edit Subtasks. If this task is stalled on an upstream project, then the Upstream tag should be added. If this task requires info from the task reporter, then there should be instructions which info is needed. If this task is out of scope and nobody should ever work on this, then task status should have the "Declined" status.)