# create a systemd service without write access to /etc/systemd/system

**URL:** <https://forum.ansible.com/t/create-a-systemd-service-without-write-access-to-etc-systemd-system/37055>\
**Category:** Ansible Project\
**Created:** [September 1, 2022, 5:15am UTC](https://forum.ansible.com/t/create-a-systemd-service-without-write-access-to-etc-systemd-system/37055 "2022-09-01T05:15:42Z")\
**Posts on this page:** 8\
**Page:** 1

<div class="post-metadata">

**Author:** ![dulhaver](https://sea1.discourse-cdn.com/ansible/user_avatar/forum.ansible.com/dulhaver/32/1061_2.png) [@dulhaver](https://forum.ansible.com/u/dulhaver)\
**Post date:** [September 1, 2022, 5:15am UTC](https://forum.ansible.com/t/create-a-systemd-service-without-write-access-to-etc-systemd-system/37055/1 "2022-09-01T05:15:42Z")

</div>

I need to create a postgresql@[db\_service\_name].service for systemd on remote hosts. Based on extremely limited access rights on such hosts (due to strict company security policies) the challenge I am facing is that the only way to do this manually is via

&nbsp;&nbsp;&nbsp;sudo systemctl edit --full postgresql@[db\_service\_name].service

This allows to edit a unitfile interactively which then is used to start the service.  
I do not have any direct write access to /etc/systemd/system or anything else outside /opt on such remotes.

so, is there any way to get specific values into that unit file via ansible under such circumstances?

---

<div class="post-metadata">

**Author:** ![Andy\_Smith](https://avatars.discourse-cdn.com/v4/letter/a/898d66/32.png) [@Andy\_Smith](https://forum.ansible.com/u/Andy_Smith)\
**Post date:** [September 1, 2022, 11:51am UTC](https://forum.ansible.com/t/create-a-systemd-service-without-write-access-to-etc-systemd-system/37055/2 "2022-09-01T11:51:47Z")

</div>

Hi,

> the challenge I am facing is that the only way to do this manually  
> is via
> 
> &nbsp;&nbsp;&nbsp;sudo systemctl edit --full postgresql@[db\_service\_name].service

If you can use sudo then can you not just do the equivalent of

sudo cp /some/temp/file /etc/systemd/system/whatever.service

?

How locked down exactly is your sudo access? I'd have thought that  
if you can issue "sudo systemctl edit" then you can easily cook up  
something that can give you arbitrary access, so this restriction  
seems like more of an "honour system", i.e. a determined attacker  
who realises they can do "sudo systemctl edit" will not be stopped.  
So on that basis maybe they will allow "sudo cat …" also.

Cheers,  
Andy

---

<div class="post-metadata">

**Author:** ![Walter\_Rowe](https://sea1.discourse-cdn.com/ansible/user_avatar/forum.ansible.com/walter_rowe/32/4506_2.png) [@Walter\_Rowe](https://forum.ansible.com/u/Walter_Rowe)\
**Post date:** [September 1, 2022, 12:07pm UTC](https://forum.ansible.com/t/create-a-systemd-service-without-write-access-to-etc-systemd-system/37055/3 "2022-09-01T12:07:30Z")

</div>

Nope. Ansible uses sudo to elevate privileges on Linux. If you don’t have a service account that can sudo, you can’t do this with ansible. Your service account is the “remote\_user” that ansible uses to SSH into the machine. The sudoers file must grant this account sudo rights.

It does not have to be passwordless sudo. You can provide a variable ansible\_become\_password that contains the sudo password. There are many ways to do that. The most secure way would be an ansible vault. This is essentially an encrypted vars file. You provide the vault secret when you run the playbook. On your command line you would do something like this.

$ ansible-playbook my\_playbook.yml -e @my\_vault.yml --ask-vault-pass

The @my\_vault.yml tells ansible-playbook to source the my\_vault.yml for its extra\_vars. The --ask-vault-pass prompts you for the vault secret. Your my\_vault.yml file would look like this:

---

<div class="post-metadata">

**Author:** ![shearn](https://avatars.discourse-cdn.com/v4/letter/s/ba8739/32.png) [@shearn](https://forum.ansible.com/u/shearn)\
**Post date:** [September 1, 2022, 4:07pm UTC](https://forum.ansible.com/t/create-a-systemd-service-without-write-access-to-etc-systemd-system/37055/4 "2022-09-01T16:07:09Z")

</div>

The sudo privileges granted to “remote\_user” needs be to be limitless. Execute ALL commands as ALL users. One cannot restrict to executing a single binary like ‘useradd’ because it’s running a module with a random name.

It’s either all or nothing.

Regards,

Stan

---

<div class="post-metadata">

**Author:** ![Kevin\_Shumaker](https://avatars.discourse-cdn.com/v4/letter/k/eb9ed0/32.png) [@Kevin\_Shumaker](https://forum.ansible.com/u/Kevin_Shumaker)\
**Post date:** [September 1, 2022, 4:22pm UTC](https://forum.ansible.com/t/create-a-systemd-service-without-write-access-to-etc-systemd-system/37055/5 "2022-09-01T16:22:22Z")

</div>

When confronted by a lack of privileges to be able to accomplish certain tasks given to me, I’ve usually resorted to creating a ticket with my ‘resolution’, and escalating to the SysAdmins and let them ‘deal’ with the issue. (Usually limited access on specific servers). If they get enough tickets, the Manager or Director usually takes notice, and either grants specific access or transfers the responsibility to the SysAdmins. (What usually happens shortly thereafter is it gets placed back in my lap, with needed privileges as they SysAdmins are already too busy, which is why it was placed in my lap to begin with…) Either resolution is a win.

---

<div class="post-metadata">

**Author:** ![dulhaver](https://sea1.discourse-cdn.com/ansible/user_avatar/forum.ansible.com/dulhaver/32/1061_2.png) [@dulhaver](https://forum.ansible.com/u/dulhaver)\
**Post date:** [September 2, 2022, 4:44am UTC](https://forum.ansible.com/t/create-a-systemd-service-without-write-access-to-etc-systemd-system/37055/6 "2022-09-02T04:44:49Z")

</div>

system access is granted pretty specific (and pretty limited). The fear is not so much a hacker but our own staff should only be able to execute very specific commands (and creating anything in /etc not bein one of those for a member of the database team) he or she is supposed to execute.

@kevin.shumaker: thks, I was hoping to find away around playing such kind of pingpong, but it looks like there is none, so I’ll have to play along.

---

<div class="post-metadata">

**Author:** ![dulhaver](https://sea1.discourse-cdn.com/ansible/user_avatar/forum.ansible.com/dulhaver/32/1061_2.png) [@dulhaver](https://forum.ansible.com/u/dulhaver)\
**Post date:** [September 2, 2022, 5:17am UTC](https://forum.ansible.com/t/create-a-systemd-service-without-write-access-to-etc-systemd-system/37055/7 "2022-09-02T05:17:22Z")

</div>

I am wondering whether granted limited write access to the postgres user (who is the one executing that TASK) to only write files like postgresql.\*.service inside /etc/systemd/system could be a solution. I guess using the template module would be the way to do this.

[postgres@server\>](mailto:postgres@server%3E) sudo -l looks like this exerpt

(root) NOPASSWD: /usr/bin/cat /var/log/messages, /usr/bin/zcat /var/log/messages-_, /usr/bin/systemctl restart  
postgresql.service, /usr/bin/systemctl reload postgresql.service, /usr/bin/systemctl status postgresql.service,  
/usr/bin/systemctl restart postgresql@_.service, !/usr/bin/systemctl restart postgresql@_…_,  
!/usr/bin/systemctl restart postgresql@_[[:blank:]]_, /usr/bin/systemctl reload postgresql@_.service,  
!/usr/bin/systemctl reload postgresql@_…_, !/usr/bin/systemctl reload postgresql@_[[:blank:]]_,  
/usr/bin/systemctl status postgresql@_.service, !/usr/bin/systemctl status postgresql@_…_, !/usr/bin/systemctl  
status [postgresql@_[[:blank:]]_](mailto:postgresql@*%5B%5B:blank:%5D%5D*)

so based on this I wonder whether this could be achived whether I could identify the local command executed by the template module in order to create the file on the remote. Or is that thinking down the wrong road?

---

<div class="post-metadata">

**Author:** ![dulhaver](https://sea1.discourse-cdn.com/ansible/user_avatar/forum.ansible.com/dulhaver/32/1061_2.png) [@dulhaver](https://forum.ansible.com/u/dulhaver)\
**Post date:** [September 2, 2022, 11:21am UTC](https://forum.ansible.com/t/create-a-systemd-service-without-write-access-to-etc-systemd-system/37055/8 "2022-09-02T11:21:27Z")

</div>

it has turned out that our entire approach creating the postgres service needs to be different and that the different approach provides an editable .env file.  
So this was kind of a false alarm, sorry
