web program today: why is online web program user =/= Unix user in /etc/passwd

Question

History and explanation

In the early days of Unix,

... as Unix was invented as a network and multi-user operating system; you could deploy web server programs on Unix where the online user in the program was the same as (equaled) the actual user (registered in /etc/passwd with a number higher than 1000) on the Unix machine (correct me if I am wrong).

Nowadays,

...this is mostly not the case anymore. Today, every web server program, which wants to be for multiple online users, also includes multi-user support written in the same program. The web server program then only runs under one user, normally this user is called the same as the program (e.g. Apache may be deployed under the user apache or www-data).

Comparison

Disadvantages of today's normal setup

administration is mostly only possible via the web server program (either CLI, GUI or conf files).
I would say, administration gets a little bit more complicated and intransparent. Because by limiting it only to one user; but then creating multiple users inside the application / the applications home directory; the whole concept of multi-user operating system is misused in my perception. Isn't it better it to use things like SELinux or limiting access rights by putting those peoples in system groups: You could for example put all online users in a system group called online-users. Then you could deny all members of this group to execute any program on your server, except of the web server programs that you configured before. This would also make sharing data between multiple web server applications on the same server much easier.
Every programmer, who wants to make an online web-server program; also has to program the multi-user support and harden each user from each other, so that no user can get access to other users data or passwords => double work!
This way, online users (inside the web server application) vs system users on the server are protected very good; but the online-user-vs.-online-user-protection level on the same server depends on the programming skills of the web program programmer.

Advantages of today's normal setup:

more security: by limiting all online action and data to only one user (so to say: sandboxing) who has got no root/sudo rights and only ONE program (without SUID bit, of course).
portability: the web server program can also be used on non-unix systems. But come on: Windows or Mac OS X Servers are rarely used as web server operating systems; that is not a really big advantage.

Are there any more advantages? If this is the only advantage (I don't count the second one as relevant ...), I would count this whole thing as a good example where security was more important than usability / comprehensibility / transparency.

Apart from that, I think there are more advantages I did not mention.

I guess you understand what I mean; and I do not have to provide examples. If you do not not understand what I mean to say, I can give some examples.

TL;DR:

Why does no web program (for POSIX-based-OS) exist anymore today; in which:
online user, registered with web program == system user, registered in /etc/passwd with a number > 1000.
What are the advantages and disadvantages with each setup (setup today: =/=, possible setup: ==)?

I could not find any website or other serverfault question dealing with this matter more than incidentally in a sub-ordinate clause, if you know one website or question; please let me know.

My apologies, but I can't tell if you have a genuine point or if your question is a rant in disguise. And if it is a question, what is it you actually want to know? — HBruijn, Jun 29 '16 at 21:53
Are you asking why for instance the 1.6 billion Facebook user don't have interactive user accounts on Facebook's Web servers but only exist in Facebook's website/webapplication? — HBruijn, Jun 29 '16 at 21:57
Basically, because it's much easier and secure for a web application to store and manage user credentials in its own database, rather then messing arround with system user accounts. — Massimo, Jun 29 '16 at 21:58
As a side note, in the Windows world many web applications (especially enterprise ones) actually use the system (or domain) credentials to authenticate users; that's especially common in Active Directory environments, where AD already *is* a global user database shared by all computers in the domain, and application users are expected to have an account there. — Massimo, Jun 29 '16 at 21:59

BillThor · Answer 1 · 2016-06-29T22:16:50.093

Time have changed. There was a time when every system's administrator could be reached at the hostmaster address for that server. Connectivity once depended on knowing an administrator who would allow you access, and a routing map between systems was regularly published. Those days are long gone and security threats are wide-spread.

The userid > 1000 issue is a red herring. It is common practice to reserve UIDs < 1000 for system service accounts. One of these is commonly www-data which often used by the Apache web server. Services on these UIDs are likely controlled by the servers administrator. This means if I can reach the administrator, they will likely be aware of the application and able to do something about it.

All the servers I am aware of could care less what the users UID is. If a developer wants to run a web server, tomcat ..., they are free to do so on an non-privileged port (see below).

The privileged ports (1 to 1024) generally require root access to be opened. This assures other administrators that the service on that port has the blessing of the administrator of that server. The unprivileged ports (1025 and above) can be used by any user if they are not already in use.

On a multi-user system you can't have a bunch of users all trying to run a service on a well-known-port such as port 80. Only one user can bind the port at a time. Programs such as Apache make allowances for this and each user can have their own public_html directory where they can publish web content, including the ability to run scripts from that directory. The availability of this function is up to the administrator to configure.

While for testing purposes almost anyone can start a server for a well-known service. However, many of these have issues that the casual user/developer would not be aware of. Many web sites and marketing servers are configured to send mail in a way that makes it difficult to tell that the server is legitimate. Major providers like Google, Microsoft, and Yahoo are making it increasing difficult to send them mail if your don't get rDNS, SPF, DKIM, and DMARC configured correctly.