1

I created the user uwsgi and the group uwsgi for using them as uid and gid in .ini-file for uwsgi properties. I didn't set password for this user (didn't run sudo passwd uwsgi, actually, I can't login as uwsgi). It is safe to use the user as a process owner for uwsgi processes? Or it is a bad practice and it is better to set a password for the user uwsgi?

r1d1
  • 113
  • 3

1 Answers1

3

Yes, and it is pretty much standard practice. Many daemons, for example, are run with their own dedicated username/uid (and, often, a dedicated gid) - they have no password (or a disabled password) and can't log in, but processes and cron jobs can be run with their UID.

Many of them also have /bin/false or /usr/sbin/nologin or similar as their shell.

e.g. on my Debian system, users tftp and unbound are used to run tftpd and the unbound dns resolver. One of them has /bin/false as its shell, the other has /usr/sbin/nologin - in practical terms, there's no difference.

$ getent passwd tftp unbound
tftp:x:182:187:tftp daemon,,,:/srv/tftp:/bin/false
unbound:x:188:210::/var/lib/unbound:/usr/sbin/nologin
cas
  • 1
  • 7
  • 119
  • 185
  • Also, these are often called system users, have a UID < 1000, and have no home directory. – Stewart Jun 20 '21 at 10:23
  • Most will have a home directory and it will be owned by their UID, just not usually under `/home`...technically they **all** have a home dir (as the 6th field of a passwd entry is the home dir), but sometimes it'll be something like `/nonexistent` or some other directory which doesn't exist (e.g. see `getent passwd | grep /nonexistent`). In the examples shown in my answer, `tftp`'s home dir is `/srv/tftp` and `unbound`'s is `/var/lib/unbound` – cas Jun 20 '21 at 11:42