2

Daily I look at processes on my Debian (Stretch) server using something like top or ps -aux and I see an account which is inactive

$ sudo passwd --status myuser
myuser L 12/12/2016 ...

yet, ps and top return an activity by the user, running node (which is not even installed), it last a couple of seconds each 2 min approximately and can get intensive in resources (50-90%) on one CPU.

Here is what is shown with $ top -U myuser :

PID  USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND 
                                                                                                                                      
2172 myuser+   20   0  382868 144940  34668 R  64.5  2.4   0:01.94 node

and with $ ps -e -H -O pid,ppid,stime,etime,user,args> file

PID   PID   PPID STIME  ELAPSED USER      COMMAND      S TTY  TIME     COMMAND
2172  2172  2155 11:22    00:05 myuser+   node server  S ?    00:00:02 node server

How would I investigate deeper to find how this locked user can launch this process - with the goal of preventing it?

EDIT: as suggested by @Paul_Pedant I checked this user's crontab and there is no tasks scheduled.

Also I checked mail for this user, they have daily email forwarded from root (they installed the machine in the first place so they had root access before). Email topic are cron jobs reports, as suggested in comments. But the user have no cron jobs proper. Presently investigating the daily.cron but I don't think I will find something related to the user there.

4
  • 1
    Check their crontab. Crond does not log users in, so it is quite possible that it does not check for user status. You might also check their mailbox for thousands of crond messages. Jul 12 at 20:27
  • @Paul_Pedant I will investigate following your suggestions and update my question
    – marsisalie
    Jul 12 at 20:40
  • It's only a guess, but "each 2 minutes" is possibly a give-away. It could also be a script that restarts itself with at. If the account was locked in 2016, then it must be something that survives reboots. Jul 12 at 20:44
  • 1
    use ps -ef | grep $pid to have a clue, or even more ps -e -H -O pid,ppid,stime,etime,user,args> file when "ghost user" appear so you can inspect at leisure.
    – Archemar
    Jul 13 at 14:52
1

The most likely situation is that the user has a cronjob that is running periodically.

Here are some less likely scenarios.

It is possible that there are multiple usernames mapped to the same UID in /etc/passwd. You might be using LDAP or Active Directory authentication, and the /etc/nsswitch.conf is obtaining passwd entries from multiple sources with the same UID. ps and top would show the first username that it finds for a given UID.

There could be a program running as root that is spawning new processes with a UID. For example, an apache webserver might be configured to connect to node via fastcgi and launch node automatically with a different UID. https://httpd.apache.org/mod_fcgid/mod/mod_fcgid.html

It doesn't matter if node is installed by root, since an executable could be copied to the user's home directory.

1
  • Good suggestions. I checked UID: each are unique in passwd. No LDAP / AD auth. Will investigate if other programs can be spawned and provide an update.
    – marsisalie
    Jul 13 at 14:45
0

Docker was the reason.

Details here: https://forums.docker.com/t/confusion-about-the-user-a-process-run-as/48702/2

UID 1000 on the host is locked.

Yet, Docker launch processes under UID 1000 inside containers, which are shown as a process launched by the locked user when looking at processes on the host.

Obviously, the UID 1000 inside the container is not the same than the one on the host. And 1000 being likely used since it is the default first available ID when adduser is executed.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.