Page MenuHomePhabricator

Suggesting addition to tool labs documentation regarding tools that delibrately chmod their tool home dirs o-rx
Open, Stalled, 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 project: Cloud-Services. · View Herald TranscriptMay 2 2017, 3:48 PM
Restricted Application added a subscriber: Aklapper. · View Herald Transcript
zhuyifei1999 updated the task description. (Show Details)May 2 2017, 3:49 PM
bd808 triaged this task as Normal 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 claimed this task.Aug 28 2018, 8:20 PM
srodlund changed the task status from Open to Stalled.Aug 29 2018, 10:31 PM
srodlund lowered the priority of this task from Normal to Low.

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

srodlund moved this task from Backlog to Quick fixes on the User-srodlund board.Sep 11 2018, 7:47 PM
srodlund moved this task from Quick fixes to Done on the User-srodlund board.Oct 3 2018, 10:30 PM