Page MenuHomePhabricator

Tool Labs users .bashrc file does not exist for tools accounts
Open, NormalPublic

Description

User accounts on Tool Labs have a .bashrc file that is managed by puppet, that sets ls to use colour, adds ls aliases, and some other stuff. The file is not automatically added for tool accounts. I don't know whether this behaviour is intended or not, but it would be extremely useful to have it for tool accounts.

Event Timeline

tom29739 created this task.Apr 1 2016, 11:17 PM
Restricted Application added a project: Cloud-Services. · View Herald TranscriptApr 1 2016, 11:17 PM
Restricted Application added a subscriber: Aklapper. · View Herald Transcript
scfc added a subscriber: scfc.EditedApr 2 2016, 1:19 AM

The ~/.bashrc file for users does not come from Puppet, but from the bash package:

scfc@tools-bastion-05:~$ dpkg-query -S /etc/skel/.bashrc 
bash: /etc/skel/.bashrc
scfc@tools-bastion-05:~$

When a user logs in for the time, the home directory gets created and prefilled from /etc/skel by pam_mkhomedir.so.

I think nowaways that module is also triggered by tools with sudo (/etc/pam.d/sudo => @include common-session-noninteractive => session [success=ok new_authtok_reqd=ok default=ignore] pam_mkhomedir.so umask=0077), but as toolwatcher will create the tool's directory usually before the user sudos to become the tool, there is an existing (almost empty) home directory for the tool account, so pam_mkhomedir.so doesn't copy /etc/skel over.

toolwatcher creates ~/public_html (which one could do without), but more importantly sets the setgid bit on a tool's home directory, so the umask part of the PAM rule would need to be split between user accounts (where the group wikidev is shared with all user and thus files should not be readable/writable by the primary group) and tool accounts (where that is the whole point).

tom29739 added a comment.EditedApr 2 2016, 1:32 AM

It says it's managed by puppet:
'## THIS FILE IS MANAGED BY PUPPET as template('base/environment/skel/bashrc')##'.

scfc added a comment.Apr 2 2016, 1:35 AM

@tom29739: I'm sorry, you are right. I meant the mechanism by which the file lands in the home directories and did not check its contents.

tom29739 added a comment.EditedApr 2 2016, 1:44 AM

@scfc If the toolwatcher command runs when the tool is created, then why not have it run when the tool account is first logged into instead? Then the PAM rule would run first, then the toolwatcher command would run and create the public_html directory and set the setgid bit.

chasemp triaged this task as Normal priority.Apr 4 2016, 1:39 PM
scfc added a comment.Nov 24 2016, 12:21 PM

(The duties of toolwatcher have been passed onto maintain-kubeusers and ~/public_html is no longer created.) I believe that currently a lot of logic depends on "home directory does not exist" → "do this and that", so changing it is much risky work with not very much benefit (and understanding the PAM flow makes my brain hurt :-)). But in theory your concept should work.

scfc moved this task from Triage to Backlog on the Toolforge board.Dec 5 2016, 4:00 AM

maintain-dbusers is currently after maintain-kubeusers to avoid race conditions, checking for the home directory's existence before it gets run. It shouldn't be too hard/risky to do the same for maintain-kubeusers.

scfc reopened this task as Open.Feb 9 2017, 12:58 AM

T91235 would be one possible solution (and IMHO the most beautiful), but there are other ways to do this, for example by copying /etc/skel in maintain-dbusers/maintain-kubeusers.

Dalba added a subscriber: Dalba.Feb 27 2019, 7:50 AM