How do I run as a system user?

English Applications
#1

I need to edit my Web server files. They all are owned by wwwrun:www. I therefore want to do things as user wwwrun from a shell to keep ownerships correct.
I start from a root shell, and do


# su -- wwwrun -s /bin/bash# whoamiroot

Solved this:
sudo -u wwwrun -s /bin/bash

#2

Yes, first read the man page:

man su
#3

BTW maintaining the web-pages as wwwrun (or as another user in group www) is first and for all because you should never do things as root that have no need to be done as root. Keeping ownership correct is only one of the results if this sound policy.

Another BTW, I should always add the --login (or -l, or -) option to su. Gives you the correct environment (amongst them PATH).

#4

You will experience an issue if your attempt to login to a CLI as the user “wwwrun”:

wwwrun:x:30:8:WWW daemon apache:/var/lib/wwwrun:/bin/false

Please note the 7th field of the ‘/etc/passwd’ entry for the user “wwwrun”: “/bin/false”.

  • “This is the program to run at login” – “If set to a nonexistent executable, the user will be unable to login through login(1).
    ” - The CLI command “false
    ” does this:

do nothing, unsuccessfully

[HR][/HR]Therefore, do not assume that, you can login as the user “wwwrun” – you can’t …
[HR][/HR]Instead do this:

  • Create a system account (an administrator account) associated with the group “wwwrun” – “useradd --gid wwwrun --system”.

Now we have an issue:

  • Wordpress uses the file ownership pattern “wwwrun:root”.
  • Drupal 8 uses the file ownership pattern “wwwrun:www”.

Meaning, having an admin user simply associated with the group “wwwrun” will not work because, of the group privileges on the Web server directories.

  • You’ll also have to associate the admin user to the group “root”.

Once you’ve done all that, you’ll still have an issue:

  • Any file operations done the new admin user will probably drop the “user/group” of the admin user onto the file being operated on …
  • You’ll have to ensure that, on completing any file operations you have checked that, the file ownerships are correct.
#5

Recommend…
Give yourself permissions however you wish that meets your security objectives to edit your files… Either by granting permissions to your own User account or to a group and make your User a member of that group. I’d suppose using “sudo” or more properly “su -” to the specific User account could work <if> the User account can be logged in interactively (many can’t and are set up that way specifically to protect against hacking if something serious fails).

If ownership is that important to you,
Then modify the permissions of the subdirectories and files to automatically inherit the Owner permissions of the parent folder.

TSU

#6

I’m not currently running a webserver. When I was last running one, I don’t think I ever tried to do what you want. I used the group permissions to allow me to create files for the web server. Whether those files were owned by “wwwrun” mostly did not matter. The web server is reading them, but not writing them.

#7

In fact the same here. I hinted already to that above.

I left wwwrun as it is (you could e.g. change the /bin/false to /bin/bash and then login).
I created a new user with primary group www and that one owns most of the files. Because if group permissions, user wwwrun (and thus Apache) can serve them.

I also have another server root defined with Alias. Here a normal user is owner, but as long as he makes his files world redable, there is no problem in serving them.

#8

Options on what to set up probably depends on the User’s security objectives.
My understanding is that wwwrun is normally used to sandbox any website activity (normal or hacked) to the website, and unable to do anything else on the system.

Logs ordinarily are also used to record events and activity.

If the User is trying to do something else, YMMV.
If the User wants to prevent or at least make hacking/defacing very difficult or next to impossible,
I’d suggest perhaps looking at openSUSE Transactional Server where the files on disk are RO and even system changes can’t be applied until the next system reboot. Even if “in memory” processes might be compromised, a simple reboot would likely reset the website and any “resident only in memory” would be cleared.

TSU