Yeah my reading comprehension process maxed out a core on this one.
> First, you almost certainly operate a variety of services that normally only use Unix logins as a source of (password) authentication and perhaps a UID to operate as, and ignore the login's shell. This is the common pattern of Samba, IMAP servers, Apache HTTP Basic Authentication, and so on.
So you have a user on your server
nginx:x:100:101:nginx:/var/lib/nginx:/sbin/nologin
And your also running samba network shares, you point your samba client at your server and use user nginx and inexplicably the password you also set for that user to login? This a service is using etc/shadow basses authentication but not sending the message in /etc/nologin
.. presumably samba won’t work really in this case..
>In some cases you may be able to teach these services to look at the login's shell and do special things, but some of them are sealed black boxes and even the ones that can be changed require you to go out of your way. If you forget one, it fails open (allowing access to people with an administrative shell that should lock them out
Is this talking about setting up applications..like a web server, that would give a http access to a uses home for,
And having these services authenticate with the servers etc/shadow or configured Pam providers, and also then check out the shell in /etc/password to gracefully handle access management and error messages?
Mh. I think the problem is: There are (at least) 2 fundamentally different use cases for linux/unix systems.
One is what I'd call a shell-server. On a shell-server, I have a bunch of accounts for users, and there are services supplied for these users. There will be /home/tetha, and /home/tetha/share and /home/tetha/http. And then you have some SMB sharing /home/*/share and you login there with your password, Apache serves /home/*/http for the intranet and so on. This is a very common setup at universities, for example.
The other thing is what I'd call an application server or a service server (but that name sucks). Here, you have a system and the main purpose of the system is to serve a web page via nginx, or be a postgres node and such.
These service-systems tend to be both more controlled, but also simpler. You need to grant a rather small, very known set of users access to these - 10 - 30 usually. And, honestly, these service-level systems tend to have very streamlined permissions, because realistically, shell-access is enough attack profile to be considered root access unless you are very diligent.
Shell-servers however are very, very complex to handle. One big shell-server can be overall more complex than many infrastructures around in total.
> First, you almost certainly operate a variety of services that normally only use Unix logins as a source of (password) authentication and perhaps a UID to operate as, and ignore the login's shell. This is the common pattern of Samba, IMAP servers, Apache HTTP Basic Authentication, and so on.
So you have a user on your server nginx:x:100:101:nginx:/var/lib/nginx:/sbin/nologin
And your also running samba network shares, you point your samba client at your server and use user nginx and inexplicably the password you also set for that user to login? This a service is using etc/shadow basses authentication but not sending the message in /etc/nologin .. presumably samba won’t work really in this case..
>In some cases you may be able to teach these services to look at the login's shell and do special things, but some of them are sealed black boxes and even the ones that can be changed require you to go out of your way. If you forget one, it fails open (allowing access to people with an administrative shell that should lock them out
Is this talking about setting up applications..like a web server, that would give a http access to a uses home for, And having these services authenticate with the servers etc/shadow or configured Pam providers, and also then check out the shell in /etc/password to gracefully handle access management and error messages?