If you want a program/process in Linux to access files and folders with limited access you create a system user for this program/process to use:

useradd -r USERNAME

How do you then map the user name with the program/process? For example how does Apache web server run and authenticate as it's user name "www-data"?

Best regards

Not entirely sure if I understand the question, but you can get a "forest view" to see how process relate to eachother using the ps command with the f option (no tac, just f).. For example, ps -a f will give you a forest view of processes other people are running... Depending on the system you may need to leave out the tac on the -a option aswell; so it may also be like ps a f or ps aux f (view daemons and how they relate to eachother)..

notes:
www-content could be substituted for www-data

This appears to be a similar discussion to this one
The apache web server username is defined in httpd.conf - that user should already exist (it would have been set up by the apache install). You don't need to do anything special for apache to run/authenticate. If I've missed the point of your question, please clarify.

Sorry I did misunderstand the question, to map the program/process to another user you make it a setuid program in order to change the effective userID (euid) to that of the system account you created.. The euid is the UID of an account whose privileges attach to a process.. So with the setuid bit set, the euid will be changed to that of the system account so that when you run the program it will run with the permissions of the system account instead of the real userID (ruid).. But in order to do that make sure that USERNAME owns the file, because as I said before, the way setuid works is that it changes the euid to that of the file's owner so that when the program runs it runs with the permissions of the file's owner, instead of the ruid (ruid or "real userID" is the user who starts the program, and the euid is usually the same UID as this, UNLESS changed otherwise by setuid).. Then to add a layer of security you can make a group and specify that only users within that group may execute the setuid program.. This all sounds complicated but if you read up on setuid, euid, and ruid it'll all start to make sense... Setuid is usually used for normal users to escalate to root temporally carrying out tasks as root, then dropping back down to it's regular privileges once those tasks complete (like sudo, which is a setuid program).. But it doesn't have to be done that way, you can use it anywhere the concept applies.. Setuid programs running as root can be a vulnerability, but setuid programs running as a system account that doesn't need root, shouldn't be an issue..

I will try to explain what I mean with another example.

If I my self for example creates a program/process named TestDeameon and then create a system user with user name TestDeamonUser, how will the Linux system now that TestDeamon belongs to TestDeamonUser and how will TestDeamon authenticate itself?

In the case of apache, theres a http[d].conf type thing that tells it where it exists. And various other configs for things like minidlna to tell it where it's legos are placed. But it entirely depends on the process. Otherwise the user who launches the thing is what the thing runs as, as viewable in the ps output. And whatever that user has access to, it has access to. Baring "extras" which may not be installed or enabled by default.

$ ps -Al

$ ps -aux

1 members found this post helpful.

When you launch a process, say with "systemd," you can specify the user that it should run as.

A program/process is not specifically associated with any user at all. The file(s) from which it comes have "owners," as do any and all files, but processes do not ... unless the "setuid" feature is used. (This is normally used only so that non-rootly users can run programs which can do rootly things.)

1 members found this post helpful.

1) chmod u+s TestDaemon (makes it setuid executable)

2) groupadd Adminz ; usermod -aG Adminz User1 ; dpkg-statoverride --update --add TestDaemonUser Adminz 4750 /path/to/TestDaemon

(creates group "Adminz" and adds User1 to that group, and then modifies permissions of "TestDaemon" so that "TestDaemonUser" owns the file, and so that only users in the "Adminz" group can execute the file; in this case it set so that only User1 can execute the program, but you can add more users in the Adminz group which would grant them access aswell)

3) usermod -L TestDaemonUser (locks the system account "TestDeamonUser" from being able to login, for security purposes)

1 members found this post helpful.