I learned something today! Testing service accounts...

Submitted by k-admin on Tue, 12/14/2021 - 19:03

Alternate title: Things you discover when you read the fine manual!

The one-liners will happen, but are going to be on hold as I devote my work time to training, and my down time focused on personal stuff as Red Hat are very big on a healthy work-life balance. With that, I am organizing my whole life - I've been wanting to finally finish my office, so I am working in my living room as I work on the office and sorting through the years of clutter and computer gear I've collected. It's been fun. I've also started on atkins/keto again, as the long hours I was working for my last year at my former employer, and even more so around the time I was preparing to leave my former employer as I knew I was going to blow the whistle on employment and business ethics; all of this extra workload caused me to be very sedentary, more so the last couple of months at my old job. I've gotten active again and am starting to hit the gym, but am still spending much of my personal time on home organization and getting through a massive backlog of a honey-do list I maintain as I tend to home projects I've been wanting to get done.

But that is not the point of this post. The point of this post is I learned something today! 

Have you ever wanted to test a service account? Maybe you knew this already, but I never did - the heat of the moment in firefighting on escalations at Rackspace never afforded me the time to really sit and relax and work on my own learning. I've often wanted to audit custom service accounts I've set up, and have typically set up /bin/bash as the shell to make the account a user account for testing, and then lock it down after the fact, but how do I test a service account without modifying it? I've often wanted to log into a service account to test access when applications break. How do I do this?

Well, today I decided to actually sit down and spend two minutes reading the su man page, and it was so obvious. I checked with other senior engineers at my level of experience, and with one old neckbeard-level old school *nix admin, and none of them knew this:

You can actually log into a service account with su by leveraging the --shell switch.

No, really -- TRY IT!!! Here, I will use "nobody" as the example: 

[klazarsk@kim ~]$ sudo su - nobody --shell=/bin/bash
[sudo] password for kim: [proprietary banner removed]
[nobody@klazarsk /]$ whoami;id
nobody
id=65534(nobody) gid=65534(nobody) groups=65534(nobody) context=unconfined_u:unconfined_r:unconfined_t:s0-s0:c0.c1023
[nobody@kim /]$

 

It's mind-boggling to me as in conversations past and present colleagues and I haven't known how to log into these accounts without a chsh (or manual editing of /etc/passwd) to test them, and yet it's been right in the man page all along. There have been similar "discoveries" I've made by actually making the time to sit down to read a man page and have had people insist, quite aggressively at times, that I was wrong, only to find that when they test, they find that not only was what I "discovered" correct, it was plainly documented in the man page. One example I have from about six years ago which sticks out in my mind was %CPU reported by the process table as reported by ps; it is not %cpu at the moment but an average over the process's lifetime, so mysql could be pinning all cores at 100% but still show 1% according to ps. Even with a demonstrable case, it was an uphill battle to get automated %cpu report ticket updates and the way techs handle %cpu and proc queue tickets changed. These mind-numbingly simple issues we gloss over leads me to wonder just how much more efficiently we could leverage userland tools' native functionality as we never make time to read the documentation of the most basic tools we use on a daily basis.