We have a Linux machine on which we run our .NET Core app. This app is a web UI which is used to display and configure a system of EEPROMs. The app reads the dhcpd.leases file, located in the directory /var/lib/dhcp, and displays the IP address of each EEPROM in the UI.
When a new EEPROM is added to the system, its IP address is added to the dhcpd.leases file and thus it shows up in the UI. But when an EEPROM is removed from the system, its IP address isn't removed from the dhcpd.leases file and thus it continues to be shown in the UI.
We want to allow the user to be able to remove an EEPROM from the UI when it has been physically removed from the system.
When a user removes an EEPROM from the UI, we want its IP address to be removed from the dhcpd.leases so that it won't be shown again.
This isn't possible, since the default permissions on the file give read and write permission only to the owner (there's no owner listed), give read-only permission to the dhcpd group and other users, and don't allow it to be executed. By running the command sudo chmod 777 /var/lib/dhcp/dhcpd.leases, the file permissions can be changed and thus the app is able to modify the file as we want it to. However, whenever the system reboots, the file permissions are reverted. Our Linux machine uses systemd services to start the app whenever the system starts up, so I thought creating a systemd service would be the best way to ensure the command to change the file permissions is executed when the system starts up. I created a file named dhcp.service in the directory /etc/systemd/system which looks like this:
[Unit]
Description=change dhcpd.leases permissions
[Service]
Type=oneshot
WorkingDirectory=/var/lib/dhcp
ExecStart=chmod 777 dhcpd.leases
User=root
[Install]
WantedBy=multi-user.target
I then ran the command systemctl enable dhcp.service. But even after rebooting the system, the file permissions still weren't changed. I ran the command systemctl is-enabled dhcp.service and that returned enabled. I also ran journalctl -u dhcp.service and the logs showed that the service ran successfully when the system started up. When I run systemctl start dhcp.service, the file permissions will successfully change. This service works as it should when it starts, but not when it's enabled, despite the logs showing that it ran successfully. I tried tips from various questions posted here and on other exchange sites but nothing has worked, so I thought I'd share my specific scenario. How can we permanently change the file permissions so that they aren't reverted when the system reboots?
We made changes to our systemd service:
[Unit]
Description=change dhcpd.leases permissions
After=isc-dhcp-server.service
[Service]
Type=oneshot
WorkingDirectory=/var/lib/dhcp
ExecStartPre=/bin/sleep 30
ExecStart=chown -R whisker:whisker /var/lib/dhcp/
User=root
[Install]
WantedBy=multi-user.target
This is a slightly different approach from what we were trying before, but it's a better approach. chmod 777 is dangerous as it makes the file readable, writable, and executable by everyone. This service instead changes the owner of the file, where whisker is the name of the user. The app runs as the user whisker, so now the app is able to read and write the dhcpd.leases file, which is exactly what we want. The owner of the entire /var/lib/dhcp directory must be changed as opposed to just the dhcpd.leases file, according to this. From what we understood, the dhcpd.leases~ file, which has the default permissions, overwrites the dhcpd.leases file from time-to-time, including the permissions that we set. This behavior can be eliminated by changing the owner of the directory. As a result, when the system reboots, the owner of the file doesn't revert.