Bug 1236363

By the way, Not sure if it is just me but on my system triggerd/unbound is not resolving anything when i resume from suspend.

On my system i worked around that by creating a dnssec-triggerd_resume.service of type one shot that is wanted by sleep.target and really just runs systemctl restart dnssec-triggerd.service

Above may or may not be related to the fact that i tested this on a system that only has a usb network (e.g. usb wireless wlan). wpa_supplicant also behaves a little weird on that system due to that.

(In reply to dac.override from comment #0)
> Description of problem:
> 
> As per the Fedora 23 dnssec feature page i set up to try it. (i maintain a
> personalized SELinux policy, and i wanted that policy to support the
> dnssec-trigger feature)
> 
> 1. the dnssec-trigger "control setup" service unit calls the restorecon
> command to reset /etc/dnssec-trigger security contexts.
> 
>     * Why is that? This should not be needed. This would just hide policy
> issues. It also sets a less than optimal precedent in that I would not want
> to have random sevice units calling restorecon out of lazyness or
> misunderstandings. Can we please remove that and then if there are issues
> with labeling of /etc/dnssec-trigger, fix those issues in the appropriate
> component (selinux-policy)
> 
>    (BTW this also applies to the unbound "control setup" service unit)

removed...

> 2. The dnssec-triggerd service maintain a pid file in /run. Please consider
> to extend the dnssec-triggerd service unit to support this pid file with
> "PidFile=". This should ensure that the pidfile is deleted in case of an
> unclean shutdown of the triggerd service.

ok, added...

>    (BTW this also, to some extend, applies to the unbound service unit, with
> the exception that unbound does not maintain its pidfile in /run but instead
> /run/unbound. Maybe consider placing that pid file in /run as well to stay
> consistent with triggerd?)
> 
> 3. The dnssec-trigger script sets the Linux immutable bit on, i suspect,
> /etc/resolv.conf. Is there not a more elegant way to ensure integrity of
> that file?

No there is not. We are open to suggestions. There are plenty services that are trying to modify resolv.conf. Unfortunately we don't have any better way.

> 4. the dnssec-trigger script runs restorecon on
> /run/dnssec-trigger/resolve.conf.backup.
> 
>     * Why is that? This should not be needed and is not desired. SELinux
> should be transparent to the user space. This would just hide policy issues.
> It also sets a less than optimal precedence in that I wouldnt want random
> services to resort to running restorecon out of lazyness of
> misunderstandings. Can we remove that so that any labeling issues can be
> resolved in the appropriate component instead (selinux-policy)

I don't see it anywhere in the code.

>     This actually seems to break functionality because:
> 
>        If i block attempts by trigger-script to relabel
> /run/dnssec-trigger/resolv.conf.backup, then trigger-script logs an
> error/warning saying that it was not able to create the backup.
> 
>        I' am not sure if that message is accurate but i do not really see
> how this should block a backup.
> 
> Version-Release number of selected component (if applicable):
> rawhide
> 
> Additional info:
> 
> Other than the comments/suggestions above it looks pretty good to me.
> Although you may want to consider splitting out dnssec-trigger-applet. (Some
> of use do not support applets, so having that component installed is
> inefficient)

Yes, splitting the dnssec-trigger-panel into sub-package seems like a good idea. Also because GNOME folks don't seem to like panels :)

> These are just suggestions. take it or leave it obviously.


Please file separate report for unbound if possible.

Thanks!

dnssec-trigger-0.13-0.1.20150714svn.fc22 has been submitted as an update for Fedora 22.
https://admin.fedoraproject.org/updates/dnssec-trigger-0.13-0.1.20150714svn.fc22

This bug appears to have been reported against 'rawhide' during the Fedora 23 development cycle.
Changing version to '23'.

(As we did not run this process for some time, it could affect also pre-Fedora 23 development
cycle bugs. We are very sorry. It will help us with cleanup during Fedora 23 End Of Life. Thank you.)

More information and reason for this action is here:
https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora23

Package dnssec-trigger-0.13-0.1.20150714svn.fc22:
* should fix your issue,
* was pushed to the Fedora 22 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing dnssec-trigger-0.13-0.1.20150714svn.fc22'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2015-11754/dnssec-trigger-0.13-0.1.20150714svn.fc22
then log in and leave karma (feedback).

(In reply to Tomas Hozza from comment #3)


> > 4. the dnssec-trigger script runs restorecon on
> > /run/dnssec-trigger/resolve.conf.backup.
> > 
> >     * Why is that? This should not be needed and is not desired. SELinux
> > should be transparent to the user space. This would just hide policy issues.
> > It also sets a less than optimal precedence in that I wouldnt want random
> > services to resort to running restorecon out of lazyness of
> > misunderstandings. Can we remove that so that any labeling issues can be
> > resolved in the appropriate component instead (selinux-policy)
> 
> I don't see it anywhere in the code.

Does it "mv" /etc/resolv.conf /run/dnssec-trigger/resolve.conf.backup and then later restorecon /run/dnssec-trigger or somthing? I am pretty sure there is some relabeling going on that should not be.

(In reply to dac.override from comment #7)
> (In reply to Tomas Hozza from comment #3)
> 
> 
> > > 4. the dnssec-trigger script runs restorecon on
> > > /run/dnssec-trigger/resolve.conf.backup.
> > > 
> > >     * Why is that? This should not be needed and is not desired. SELinux
> > > should be transparent to the user space. This would just hide policy issues.
> > > It also sets a less than optimal precedence in that I wouldnt want random
> > > services to resort to running restorecon out of lazyness of
> > > misunderstandings. Can we remove that so that any labeling issues can be
> > > resolved in the appropriate component instead (selinux-policy)
> > 
> > I don't see it anywhere in the code.
> 
> Does it "mv" /etc/resolv.conf /run/dnssec-trigger/resolve.conf.backup and
> then later restorecon /run/dnssec-trigger or somthing? I am pretty sure
> there is some relabeling going on that should not be.

No, it' not. I investigated the package thoroughly. Feel free to download the SRPM and investigate.

dnssec-trigger-0.13-0.1.20150714svn.fc22 has been pushed to the Fedora 22 stable repository.  If problems still persist, please make note of it in this bug report.