accounts.creole

!meta title="git, shell, ldap, etc. accounts"

torproject.org Accounts

The Tor project keeps all user information in a central LDAP database which governs access to shell accounts, git (write) access and lets users configure their email forwards.

It also stores group memberships which in turn affects which users can log into which https:db.torproject.org/machines.cgi.

This document should be consistent with the [[Tor membership policy|https://gitweb.torproject.org/community/policies.git/plain/membership.txt]], in case of discrepancy between the two documents, the membership policy overrules this document.

<a id="ldap-or-alias">Decision tree: LDAP account or email alias?</a>

Here is a simple decision tree to help you decide if a new contributor needs an LDAP account, or if an email alias will do. (All things being equal, it's better to set people up with only an email alias if that's all they need, since it reduces surface area which is better for security.)

LDAP account reasons

Regardless of whether they are a Core Contributor:

• Are they a maintainer for one of our official software projects, meaning they need to push commits (write) to one of our git repos?
  • They should get an LDAP account.
• Do they need to access (read) a private git repo, like "dirauth-conf"?
  • They should get an LDAP account.

Are they a Core Contributor?

• Do they want to make their own personal clones of our git repos, for example to propose patches and changes?
  • They should get an LDAP account.
  • If they're not a Core Contributor, they should put their git repos somewhere else, like github or gitlab.
• Do they need to log in to our servers to use our shared irc host?
  • They should get an LDAP account.
  • If they're not a Core Contributor, they should put their IRC somewhere else, like pastly's server.
• Do they need to log in to our servers to maintain one of our websites or services?
  • An existing Core Contributor should request an LDAP account.
  • If they're not a Core Contributor, but they are a staff member who needs to maintain services, then Tor Project Inc should request an LDAP account.
  • If they are not a staff member, then an existing Core Contributor should request an LDAP account, and explain why they need access.

See <a href="../../howto/create-a-new-user">New LDAP accounts</a> for details.

Email alias reasons

If none of the above cases apply:

• Are they a Core Contributor?
  • An existing Core Contributor should request an email alias.
• Are they a staff member?
  • Tor Project Inc should request an email alias.

See <a href="aliases">Changing email aliases</a> for details.

<a id="new-account">New LDAP accounts</a>

New accounts have to be sponsored by somebody who already has a torproject.org account. If you need an account created, please find somebody in the project who you are working with and ask them to request an account for you.

Step 1

The sponsor will collect all required information:

• name,
• initial forwarding email address (the user can change that themselves later),
• OpenPGP key fingerprint,
• desired username.

The sponsor is responsible for verifying the information's accuracy, in particular establishing some confidence that the key in question actually belongs to the person that they want to have access.

The user's OpenPGP key should be available from the public keyserver network.

The sponsor will create a ticket in https:trac.torproject.org/projects/tor/newticket in the Tor Sysadmin Team component:

• The ticket should include a short rationale as to why the account is required,
• contain all the pieces of information listed above, and
• should be OpenPGP signed by the sponsor using the OpenPGP key we have on file for them. Please enclose the OpenPGP clearsigned blob using {{{ and }}}.

Usernames are allocated on a first-come, first-served basis. Usernames should be checked for conflict with commonly used adminstrative aliases (`root`, `abuse`, ...) or abusive names (`killall*`, ...). In particular, the following have special meaning for various services and should be avoided:

root abuse arin-admin certmaster domainadmin hostmaster mailer-daemon postmaster security webmaster

That list, [[taken from the leap project|https://leap.se/git/leap_platform.git/blob/HEAD:/puppet/modules/site_postfix/manifests/mx/static_aliases.pp]] is not exhaustive and your own judgement should be used to spot possibly problematic aliases. See also those other possible lists:

• https:github.com/systemli/userli/blob/master/config/reserved_names.txt
• https:leap.se/git/leap_platform.git/blob/HEAD:/puppet/modules/site_postfix/manifests/mx/static_aliases.pp

Step n+1

Once the request has been filed it will be reviewed by Roger or Nick and either approved or rejected.

If the board indicates their assent, the sysadmin team will then create the account as requested.

<a id="retiring-account">Retiring accounts</a>

If you won't be using your LDAP account for a while, it's good security hygiene to have it disabled. Disabling an LDAP account is a simple operation, and reenabling an account is also simple, so we shouldn't be shy about disabling accounts when people stop needing them.

To simplify the review process for disable requests, and because disabling by mistake has less impact than creating a new LDAP account by mistake, the policy here is "any two of {Roger, Nick, Shari, Isabela, Erin, Damian} are sufficient to confirm a disable request."

(When we disable an LDAP account, we should be sure to either realize and accept that email forwarding for the person will stop working too, or add a new line in the email alias so email keeps working.)

<a id="get-access">Getting added to an existing group/Getting access to a specific host</a>

Almost all privileges in our infrastructure, such as account on a particular host, sudo access to a role account, or write permissions to a specific directory, come from group memberships.

To know which group has access to an specific host, FIXME.

To get added to some unix group, it has to be requested by a member of that group. This member has to create a new ticket ticket in https://trac.torproject.org, OpenPGP-signed (as above in the new account creation section), requesting who to add to the group.

If a new group needs to be created, FIXME.

The reasons why a new group might need to be created are: FIXME.

Should the group be orphaned or have no remaining active members, the same set of people who can approve new account requests can request you be added.

To find out who is on a specific group you can ssh to perdulce:

$ ssh perdulce.torproject.org

Then you can run:

$ getent group

See also: the "Host specific passwords" section below

<a id="aliases">Changing email aliases</a>

Create a ticket specifying the alias, the new address to add, and a brief motivation for the change.

For specifics, see the "The sponsor will create a ticket" section above.

<a id="new-aliases">Adding a new email alias</a>

Personal Email Aliases

Tor Project Inc can request new email aliases for staff.

An existing Core Contributor can request new email aliases for new Core Contributors.

Group Email Aliases

Tor Project Inc and Core Contributors can request group email aliases for new functions or projects.

<a id="existing-aliases">Getting added to an existing email alias</a>

Similar to being added to an LDAP group, the right way to get added to an existing email alias is by getting somebody who is already on that alias to file a ticket asking for you to be added.

<a id="password-reset">Changing/Resetting your passwords</a>

LDAP

If you've lost your LDAP password, you can request that a new one be generated. This is done by sending the phrase "Please change my Debian password" to chpasswd@db.torproject.org. The phrase is required to prevent the daemon from triggering on arbitrary signed email. The best way to invoke this feature is with

echo "Please change my Debian password" | gpg --armor --sign | mail chpasswd@db.torproject.org

After validating the request the daemon will generate a new random password, set it in the directory and respond with an encrypted message containing the new password. This new password can then be used to https:db.torproject.org/login.html (click the "Update my info" button), and use the "Change password" fields to create a new LDAP password.

Host specific passwords / sudo passwords

Please note that, after https:db.torproject.org/login.html, that the "sudo passwords" fields at the very bottom of the {{{"Update my info"}}} form DO NOT WORK.

Your sudo password is the same for all machines on which you have sudo privileges; it is your LDAP password. The mail responder at changes@db.torproject.org will take you through a plausible, and perhaps enjoyable, series of puzzles, but BEWARE: THE CAKE IS A LIE.

<a id="key-rollover">Changing/Updating your OpenPGP key</a>

If you are planning on migrating to a new OpenPGP key and you also want to change your key in LDAP, or if you just want to update the copy of your key we have on file, you need to create a ticket in https:trac.torproject.org/projects/tor/newticket in the Tor Sysadmin Team component:

• The ticket should include your username, your old OpenPGP fingerprint and your new OpenPGP fingerprint (if you're changing keys).
• The ticket should be OpenPGP signed with your OpenPGP key that is currently stored in LDAP.

Revoked or lost old key

If you already revoked or lost your old OpenPGP key and you migrated to a new one before updating LDAP, you need to find a sponsor to create a ticket for you. The sponsor should create a ticket in https:trac.torproject.org/projects/tor/newticket in the Tor Sysadmin Team component:

• The ticket should include your username, your old OpenPGP fingerprint and your new OpenPGP fingerprint.
• Your OpenPGP key needs to be on a public keyserver and be signed by at least one Tor person other than your sponsor.
• The ticket should be OpenPGP signed with the current valid OpenPGP key of your sponsor.