Update services, user, group and dir access #2
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: dhcp/kea#2
Reference in New Issue
Block a user
Delete Branch "jcronenberg/kea:master"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
control for e.g. capabilities.
These services are incompatible with the existing kea.service though and I don't see that reflected in the units.(Right, that's because kea.service is gone)
ab5bf5d6a7to0d283cf070@@ -399,0 +384,4 @@install -D -m 0644 %{SOURCE4} %{buildroot}%{_unitdir}/kea-dhcp4.serviceinstall -D -m 0644 %{SOURCE5} %{buildroot}%{_unitdir}/kea-dhcp6.serviceinstall -D -m 0644 %{SOURCE6} %{buildroot}%{_unitdir}/kea-dhcp-ddns.serviceinstall -D -m 0644 %{SOURCE7} %{buildroot}%{_unitdir}/kea-ctrl-agent.service8 9 4 5 6 7, this is terrible.
@@ -415,0 +409,4 @@%service_add_post kea-ctrl-agent.serviceif [ $1 -gt 1 ]; thenchown -R kea:kea %{_sharedstatedir}/keachown -R kea:kea %{_localstatedir}/log/keasecurity-team will not like this
I have checked it with a few people, because I also wasn't sure of this, but it seems to be the best possible solution or what would you suggest instead?
just don't change the username. "kea" is even so short someone could be using it as a normal user (and openSUSE does not use
_keausername notation like other platforms) hence the original decision to go for "keadhcp".It doesn't matter if it's
keaorkeadhcp, I chosekeabecause it's what upstream and pretty much all other distros use, no need for suseism here. And even if I don't change it, these lines would still be necessary, because the files in these dirs are currently owned byroot:rootnotkeadhcp:keadhcp.@@ -412,0 +399,4 @@%service_add_pre kea-dhcp4.service%service_add_pre kea-dhcp6.service%service_add_pre kea-dhcp-ddns.service%service_add_pre kea-ctrl-agent.servicegenerates so much shell code
wdym?
just call %service_add_pre et al once, with all args?
Ah, I didn't know about this, thx!
@@ -458,0 +460,4 @@%{_sysusersdir}/%{name}-user.conf%{_tmpfilesdir}/%{name}-tmpfiles.conf%attr(0750,kea,kea) %{_localstatedir}/log/kea/%ghost %{_rundir}/keathe diff is needlessy larger than it needs to be
wdym?
don't edit lines adding { } that don't need to be edited
I just ran a few regexes over it, I always prefer the explicit syntax for paths and I don't see what's bad about it being a bit larger diff
@@ -0,0 +1,3 @@#Type Name ID GECOS Home directory Shellg kea - - - -u kea -:kea "Kea DHCP Server" /var/lib/kea -bad idea, no transition path from existing installation
Again, I don't understand what you mean? I tested it with an existing installation and it works as expected.
0d283cf070to26feed312e@@ -0,0 +1,15 @@[Unit]no migration path from kea.service
What would you expect a "migration path" to look like?
kea.service:Requires=kea-dhcp4.service kea-dhcp6.service kea-ctrl-agent.service ddns
AFAICT this would be a bad idea, because it would start e.g. the dhcp6 service even if it was disabled by the config.
I know; but at least they run after the rpm is upgraded in the system. The alternative would be to havve Conflict=(4 services)
I won't add the
Requires=because I think this is against what this PR is trying to achieve, improving the security of the package. Personally I would keep it as is, it will require an admin to change some things yes, but that will likely be the case anyway. If you really insist I guess I can add theConflicts=kea.service.26feed312eto8c4e98db95@jengelh In my opinion this is good to go and due to some time restrictions I would like to merge this as soon as possible
@jengelh if you only merge it to then revert most of the changes that isn't what co-maintainership is about. I could have just pushed my changes as well without discussing it, but instead I wanted to discuss it with you first.
Btw
chown -Ris safe against symlink attacks, thechown -Rhisn't necessary.It's not co-maintainership, it's fallback maintainer. SUSE traditionally wanted such entries on OBS packages for packages which are in SLE, to be able to act e.g. in the face of CVE patches, if the maintainer was unavailable for a longer time. OBS's data model has long known to be inadequate to encode the basis on which a role was given/granted. You are free to remove yourself.