UNIX for Advanced & Expert Users

Expert-to-Expert. Learn advanced UNIX, UNIX commands, Linux, Operating Systems, System Administration, Programming, Shell, Shell Scripts, Solaris, Linux, HP-UX, AIX, OS X, BSD.

How to handle build user access/permissions?

👤 Login to reply

Old 01-31-2018
hburnswell hburnswell is offline
Registered User
Join Date: Jan 2014
Last Activity: 15 February 2018, 1:16 AM EST
Posts: 22
Thanks: 10
Thanked 0 Times in 0 Posts
How to handle build user access/permissions?


I am looking for some guidance on how to handle permissions/access for an application build/deployment.

We need to allow for software deployments via Visual Studio Team Services and a build server running on Windows, deploying to RHEL 7 servers. We would like to use a service account, say 'srv_user', to handle the process. The need will be to:
  1. Stop tomcat service on destination server
  2. Push latest code to destination server
  3. Do an 'ant' build of the code on destination server
  4. Start tomcat service on destination server

  • It would be great if the srv_user didn't actually need shell access on the RHEL 7 servers so developers who know the credentials can't ssh into the server. However, given the need to do a build on the destination server that may be difficult. Any thoughts?
  • We want the tomcat service to run as a different user, say 'app_user'. Since the srv_user will need to stop and start tomcat to run the build, I'm thinking to use a custom systemd service that srv_user can run but starts the service as app_user. Does this sound like the best way to handle this need or is there a better way to handle it?
  • The srv_user will be in the same group as app_user but we do want the written files to be owned by app_user. What is the best way to handle file permissions? Is there a good way for srv_user to write files as app_user or is the only way to write and then do a chown/chmod?

Hopefully I haven't confused the need too much, any suggestions are appreciated.

Thanks in advance,


Last edited by rbatte1; 02-01-2018 at 06:24 AM.. Reason: Set formatted bulletted list and numbered list
Sponsored Links
Old 02-02-2018
bakunin bakunin is offline Forum Staff  
Bughunter Extraordinaire
Join Date: May 2005
Last Activity: 3 July 2018, 11:43 PM EDT
Location: In the leftmost byte of /dev/kmem
Posts: 5,786
Thanks: 112
Thanked 1,698 Times in 1,248 Posts
Here are some general considerations/suggestions. To be more specific is too much dependant on the specific setting in your shop which is hard to appreciate from afar.

First, identify all the necessary roles and what they need to be allowed. You have already started that but you need that in more detail. Do not only define one role ("srv_user") but also the other roles necessary: i.e. "tester", "admin", ...

Only then sort through these specifications and see where they are different. i.e.:

Basic role "user": right1, right2, right3
Role "tester": like "user", but also right4, right5
Role "srv_user": like "tester" plus right6, right7, right8

This will give you a basic layout for a group hierarchy and which right should go to which group.

A few caveats: it is quite modern to use "ACLs" instead of classic UNIX privileges. This is a great way of getting yourself into deep kimchi beyond all means of maintenance. Experience shows that you end up (usually more sooner than later) with a heap of rights without any structure and no one knows or understands what is going on. Avoid that at all cost, even if it might appeal to you at first. In the long run it tends to be more a problem than a solution. A good (long-term!) solution is not one that does what you want but one that is also easy to understand and painless to maintain.

Have a look at "sudo", but do NOT overuse it! It is often possible to make up for planning deficiencies by overusage of a tool. In practically all cases this is a very bad idea in the long run. If an implementation looks cumbersome rather plan better than undergo the effort of the implementation.

I hope this helps.

Sponsored Links
Old 02-02-2018
Peasant's Unix or Linux Image
Peasant Peasant is offline Forum Advisor  
Registered User
Join Date: Mar 2011
Last Activity: 21 July 2018, 10:28 AM EDT
Posts: 1,197
Thanks: 34
Thanked 370 Times in 318 Posts
If in LAN,i would go with NFS and a cron script on the clients.

You have one windows master build server which has multiple NFS mounts from clients (destination servers) you wish to push changes to.
NFS is supported on newer windows and gid / uid can be mapped via registry to tomcat unix/linux user on clients.

A cron job runs on clients which detects if a new file is copied and does the work (stop tomcat, deploy code or whatever, start tomcat).

Be careful you do not catch files while being copied, rename a file after copy to NFS share on the build machine to file you want that client (destination server) to process.

Using NFSv4 you could probably have one port open between build machine and clients.
It would not involve any kind of access expect copying a file via network share, but some shell code running in cron should be produced.

Have you considering deploying application(s) thru web tomcat interface instead ?

Hope that helps
Old 02-15-2018
hburnswell hburnswell is offline
Registered User
Join Date: Jan 2014
Last Activity: 15 February 2018, 1:16 AM EST
Posts: 22
Thanks: 10
Thanked 0 Times in 0 Posts
@bakunin and @Peasant thank you for your replies and suggestions. My apologies for not updating this thread sooner.

What I have ended up doing is:

Created an RSA key and put it in place on the destination server to allow for passwordless SSH connections from the build server. This gives me the ability to change the password for the 'srv_user' and not have a need to distribute the password.

Created a systemd service for Tomcat so that the processes are always run as 'app_user'. The 'srv_user' connects via ssh, uses sudo to stop Tomcat via the systemd service, does the get of new files, does a build, uses sudo to change permissions back to 'app_user' owner and group, and uses sudo to start Tomcat via systemd service.

So far it seems like the best way to handle the process. I'll be fine tuning it as we progress.

Any thoughts and/or suggestions are welcome.


Sponsored Links
👤 Login to reply

Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes

More UNIX and Linux Forum Topics You Might Find Helpful
Thread Thread Starter Forum Replies Last Post
Access permissions chmod 606 Simza UNIX for Dummies Questions & Answers 7 09-03-2013 05:11 PM
Permissions and access to data treds Linux 1 08-06-2013 06:30 PM
Change access permissions Me&MyMac OS X (Apple) 3 12-17-2010 09:49 AM
file access permissions ajays UNIX for Advanced & Expert Users 1 03-03-2010 07:10 AM
root access on sun os and permissions allinone UNIX for Dummies Questions & Answers 2 03-12-2002 09:34 AM

All times are GMT -4. The time now is 07:22 PM.

Unix & Linux Forums Content Copyrightę1993-2018. All Rights Reserved.
Show Password

Not a Forum Member?
Forgot Password?