setup sudo root for new server

[Karl Auer]

On Sat, 2025-05-31 at 22:15 -0400, bruce wrote:
> I'd like to potentially have unprivileged users be able to access,
> make changes to test code on the server.
> 
> so, there might be webapps  test, testa, testb.  the users tom, Fred,
> Sam would be able to login/access the server, make code changes, as
> well as access/change the conf files

OK, so all of those users are to be allowed to modify all of the apps
and the webserver config itself, but not muck about with the rest of
the server.

As a general approach you could use group access to let them work on
the web data files and code. Put those users into the group www-data,
and make sure that all the files they may need to modify are in that
group and are group-writable.

Letting them modify the server's configuration files is trickier.

One fairly safe method would be to set up a setuid script that copies a
certain set of files over the webserver configuration files. Then give
your users write access to that set of files. They then edit those
files, and run the script to "install" them. The script would also
restart Apache to reload the overwritten configs.

A second script that creates a writable copy of the live configuration
files could also be useful. Depending on whether the live configuration
files are readable for your users, the second script might not be
necessary.

That's a very concise description, ask if you need more detail.

If these users also need to be able to run control programs like
a2enmod, you could write wrapper setuid wrapper scripts, or set up
specific sudo permissions via the /etc/sudoers file.

BTW, none of this is a good idea for a production server. For
development and testing it's fine.

You might like to think about version control, and how/whether to deal
with simultaneous access from multiple developers. As described a) last
write wins and b) developers are either all modifying the same files or
are modifying their own copies of files, so any write invalidates the
other developers' copies of those files. Some kind of deployment
pipeline would be the usual solution, but may be overkill for your
situation.

Regards, K.

-- 
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Karl Auer (kauer at biplane.com.au, he/him)
http://www.biplane.com.au/kauer