| Message ID | 20190318210913.2392-1-nicolas.iooss@m4x.org (mailing list archive) |
|---|---|
| State | Accepted |
| Headers | show |
| Series | [1/1] restorecond: use /run instead of /var/run | expand |
Nicolas Iooss <nicolas.iooss@m4x.org> writes: > On most distributions, /var/run is a symbolic link to /run so > using > /var/run or /run lead to the same result. Nevertheless systemd > started > to warn about using /var/run in a service file, logging entries > such as: > > /usr/lib/systemd/system/restorecond.service:8: PIDFile= > references > path below legacy directory /var/run/, updating > /var/run/restorecond.pid → /run/restorecond.pid; please > update the > unit file accordingly. > > Switch to /run in order to follow this advice. > > Signed-off-by: Nicolas Iooss <nicolas.iooss@m4x.org> Acked-by: Petr Lautrbach <plautrba@redhat.com> Laurent, is it acceptable for Debian? > --- > restorecond/restorecond.c | 4 ++-- > restorecond/restorecond.conf | 2 +- > restorecond/restorecond.init | 2 +- > restorecond/restorecond.service | 2 +- > restorecond/utmpwatcher.c | 2 +- > 5 files changed, 6 insertions(+), 6 deletions(-) > > diff --git a/restorecond/restorecond.c > b/restorecond/restorecond.c > index 7b984b298f79..d5f70fc2e2c1 100644 > --- a/restorecond/restorecond.c > +++ b/restorecond/restorecond.c > @@ -84,7 +84,7 @@ static void done(void) { > selabel_close(r_opts.hnd); > } > > -static const char *pidfile = "/var/run/restorecond.pid"; > +static const char *pidfile = "/run/restorecond.pid"; > > static int write_pid_file(void) > { > @@ -217,7 +217,7 @@ int main(int argc, char **argv) > write_pid_file(); > > while (watch(master_fd, watch_file) == 0) { > - }; > + } > > watch_list_free(master_fd); > close(master_fd); > diff --git a/restorecond/restorecond.conf > b/restorecond/restorecond.conf > index c64e74758d2f..1a61ece384d7 100644 > --- a/restorecond/restorecond.conf > +++ b/restorecond/restorecond.conf > @@ -2,7 +2,7 @@ > /etc/resolv.conf > /etc/samba/secrets.tdb > /etc/updatedb.conf > -/var/run/utmp > +/run/utmp > /var/log/wtmp > /root/* > /root/.ssh/* > diff --git a/restorecond/restorecond.init > b/restorecond/restorecond.init > index 775c52b0ce7c..c1cbb247fa91 100644 > --- a/restorecond/restorecond.init > +++ b/restorecond/restorecond.init > @@ -9,7 +9,7 @@ > # > # processname: /usr/sbin/restorecond > # config: /etc/selinux/restorecond.conf > -# pidfile: /var/run/restorecond.pid > +# pidfile: /run/restorecond.pid > # > # Return values according to LSB for all commands but status: > # 0 - success > diff --git a/restorecond/restorecond.service > b/restorecond/restorecond.service > index 0511a1c740ac..6bce99d39735 100644 > --- a/restorecond/restorecond.service > +++ b/restorecond/restorecond.service > @@ -6,7 +6,7 @@ ConditionSecurity=selinux > [Service] > Type=forking > ExecStart=/usr/sbin/restorecond > -PIDFile=/var/run/restorecond.pid > +PIDFile=/run/restorecond.pid > > [Install] > WantedBy=multi-user.target > diff --git a/restorecond/utmpwatcher.c > b/restorecond/utmpwatcher.c > index 62ad2e98aff3..8660520370de 100644 > --- a/restorecond/utmpwatcher.c > +++ b/restorecond/utmpwatcher.c > @@ -49,7 +49,7 @@ unsigned int utmpwatcher_handle(int > inotify_fd, int wd) > { > int changed = 0; > struct utmp u; > - const char *utmp_path = "/var/run/utmp"; > + const char *utmp_path = "/run/utmp"; > struct stringsList *prev_utmp_ptr = utmp_ptr; > if (wd != utmp_wd) > return -1;
Petr Lautrbach <plautrba@redhat.com> writes: > Nicolas Iooss <nicolas.iooss@m4x.org> writes: > >> On most distributions, /var/run is a symbolic link to /run so using >> /var/run or /run lead to the same result. Nevertheless systemd >> started >> to warn about using /var/run in a service file, logging entries such >> as: >> >> /usr/lib/systemd/system/restorecond.service:8: PIDFile= >> references >> path below legacy directory /var/run/, updating >> /var/run/restorecond.pid → /run/restorecond.pid; please >> update the >> unit file accordingly. >> >> Switch to /run in order to follow this advice. >> >> Signed-off-by: Nicolas Iooss <nicolas.iooss@m4x.org> There are other occurances of "/var/run" tree-wide. Some more important than others: cd selinux; grep -r "/var/run" . > > Acked-by: Petr Lautrbach <plautrba@redhat.com> > > Laurent, is it acceptable for Debian? > > >> --- >> restorecond/restorecond.c | 4 ++-- >> restorecond/restorecond.conf | 2 +- >> restorecond/restorecond.init | 2 +- >> restorecond/restorecond.service | 2 +- >> restorecond/utmpwatcher.c | 2 +- >> 5 files changed, 6 insertions(+), 6 deletions(-) >> >> diff --git a/restorecond/restorecond.c b/restorecond/restorecond.c >> index 7b984b298f79..d5f70fc2e2c1 100644 >> --- a/restorecond/restorecond.c >> +++ b/restorecond/restorecond.c >> @@ -84,7 +84,7 @@ static void done(void) { >> selabel_close(r_opts.hnd); >> } >> -static const char *pidfile = "/var/run/restorecond.pid"; >> +static const char *pidfile = "/run/restorecond.pid"; >> static int write_pid_file(void) >> { >> @@ -217,7 +217,7 @@ int main(int argc, char **argv) >> write_pid_file(); >> while (watch(master_fd, watch_file) == 0) { >> - }; >> + } >> watch_list_free(master_fd); >> close(master_fd); >> diff --git a/restorecond/restorecond.conf >> b/restorecond/restorecond.conf >> index c64e74758d2f..1a61ece384d7 100644 >> --- a/restorecond/restorecond.conf >> +++ b/restorecond/restorecond.conf >> @@ -2,7 +2,7 @@ >> /etc/resolv.conf >> /etc/samba/secrets.tdb >> /etc/updatedb.conf >> -/var/run/utmp >> +/run/utmp >> /var/log/wtmp >> /root/* >> /root/.ssh/* >> diff --git a/restorecond/restorecond.init >> b/restorecond/restorecond.init >> index 775c52b0ce7c..c1cbb247fa91 100644 >> --- a/restorecond/restorecond.init >> +++ b/restorecond/restorecond.init >> @@ -9,7 +9,7 @@ >> # >> # processname: /usr/sbin/restorecond >> # config: /etc/selinux/restorecond.conf -# pidfile: >> /var/run/restorecond.pid >> +# pidfile: /run/restorecond.pid >> # >> # Return values according to LSB for all commands but status: >> # 0 - success >> diff --git a/restorecond/restorecond.service >> b/restorecond/restorecond.service >> index 0511a1c740ac..6bce99d39735 100644 >> --- a/restorecond/restorecond.service >> +++ b/restorecond/restorecond.service >> @@ -6,7 +6,7 @@ ConditionSecurity=selinux >> [Service] >> Type=forking >> ExecStart=/usr/sbin/restorecond >> -PIDFile=/var/run/restorecond.pid >> +PIDFile=/run/restorecond.pid >> [Install] >> WantedBy=multi-user.target >> diff --git a/restorecond/utmpwatcher.c b/restorecond/utmpwatcher.c >> index 62ad2e98aff3..8660520370de 100644 >> --- a/restorecond/utmpwatcher.c >> +++ b/restorecond/utmpwatcher.c >> @@ -49,7 +49,7 @@ unsigned int utmpwatcher_handle(int inotify_fd, >> int wd) >> { >> int changed = 0; >> struct utmp u; >> - const char *utmp_path = "/var/run/utmp"; >> + const char *utmp_path = "/run/utmp"; >> struct stringsList *prev_utmp_ptr = utmp_ptr; >> if (wd != utmp_wd) >> return -1; >
Le 21/03/19 à 12:40, Petr Lautrbach a écrit : > > Nicolas Iooss <nicolas.iooss@m4x.org> writes: > >> On most distributions, /var/run is a symbolic link to /run so using >> /var/run or /run lead to the same result. Nevertheless systemd started >> to warn about using /var/run in a service file, logging entries such as: >> >> /usr/lib/systemd/system/restorecond.service:8: PIDFile= references >> path below legacy directory /var/run/, updating >> /var/run/restorecond.pid → /run/restorecond.pid; please update the >> unit file accordingly. >> >> Switch to /run in order to follow this advice. >> >> Signed-off-by: Nicolas Iooss <nicolas.iooss@m4x.org> > > Acked-by: Petr Lautrbach <plautrba@redhat.com> > > Laurent, is it acceptable for Debian? Yes it's OK for debian as well. /run is a symlink to /var/run here too, see point 8 at https://www.debian.org/doc/debian-policy/ch-opersys.html#file-system-hierarchy > > >> --- >> restorecond/restorecond.c | 4 ++-- >> restorecond/restorecond.conf | 2 +- >> restorecond/restorecond.init | 2 +- >> restorecond/restorecond.service | 2 +- >> restorecond/utmpwatcher.c | 2 +- >> 5 files changed, 6 insertions(+), 6 deletions(-) >> >> diff --git a/restorecond/restorecond.c b/restorecond/restorecond.c >> index 7b984b298f79..d5f70fc2e2c1 100644 >> --- a/restorecond/restorecond.c >> +++ b/restorecond/restorecond.c >> @@ -84,7 +84,7 @@ static void done(void) { >> selabel_close(r_opts.hnd); >> } >> >> -static const char *pidfile = "/var/run/restorecond.pid"; >> +static const char *pidfile = "/run/restorecond.pid"; >> >> static int write_pid_file(void) >> { >> @@ -217,7 +217,7 @@ int main(int argc, char **argv) >> write_pid_file(); >> >> while (watch(master_fd, watch_file) == 0) { >> - }; >> + } >> >> watch_list_free(master_fd); >> close(master_fd); >> diff --git a/restorecond/restorecond.conf b/restorecond/restorecond.conf >> index c64e74758d2f..1a61ece384d7 100644 >> --- a/restorecond/restorecond.conf >> +++ b/restorecond/restorecond.conf >> @@ -2,7 +2,7 @@ >> /etc/resolv.conf >> /etc/samba/secrets.tdb >> /etc/updatedb.conf >> -/var/run/utmp >> +/run/utmp >> /var/log/wtmp >> /root/* >> /root/.ssh/* >> diff --git a/restorecond/restorecond.init b/restorecond/restorecond.init >> index 775c52b0ce7c..c1cbb247fa91 100644 >> --- a/restorecond/restorecond.init >> +++ b/restorecond/restorecond.init >> @@ -9,7 +9,7 @@ >> # >> # processname: /usr/sbin/restorecond >> # config: /etc/selinux/restorecond.conf -# pidfile: >> /var/run/restorecond.pid >> +# pidfile: /run/restorecond.pid >> # >> # Return values according to LSB for all commands but status: >> # 0 - success >> diff --git a/restorecond/restorecond.service >> b/restorecond/restorecond.service >> index 0511a1c740ac..6bce99d39735 100644 >> --- a/restorecond/restorecond.service >> +++ b/restorecond/restorecond.service >> @@ -6,7 +6,7 @@ ConditionSecurity=selinux >> [Service] >> Type=forking >> ExecStart=/usr/sbin/restorecond >> -PIDFile=/var/run/restorecond.pid >> +PIDFile=/run/restorecond.pid >> >> [Install] >> WantedBy=multi-user.target >> diff --git a/restorecond/utmpwatcher.c b/restorecond/utmpwatcher.c >> index 62ad2e98aff3..8660520370de 100644 >> --- a/restorecond/utmpwatcher.c >> +++ b/restorecond/utmpwatcher.c >> @@ -49,7 +49,7 @@ unsigned int utmpwatcher_handle(int inotify_fd, int >> wd) >> { >> int changed = 0; >> struct utmp u; >> - const char *utmp_path = "/var/run/utmp"; >> + const char *utmp_path = "/run/utmp"; >> struct stringsList *prev_utmp_ptr = utmp_ptr; >> if (wd != utmp_wd) >> return -1; >
On Thu, Mar 21, 2019 at 2:31 PM Laurent Bigonville <bigon@debian.org> wrote: > > Le 21/03/19 à 12:40, Petr Lautrbach a écrit : > > > > Nicolas Iooss <nicolas.iooss@m4x.org> writes: > > > >> On most distributions, /var/run is a symbolic link to /run so using > >> /var/run or /run lead to the same result. Nevertheless systemd started > >> to warn about using /var/run in a service file, logging entries such as: > >> > >> /usr/lib/systemd/system/restorecond.service:8: PIDFile= references > >> path below legacy directory /var/run/, updating > >> /var/run/restorecond.pid → /run/restorecond.pid; please update the > >> unit file accordingly. > >> > >> Switch to /run in order to follow this advice. > >> > >> Signed-off-by: Nicolas Iooss <nicolas.iooss@m4x.org> > > > > Acked-by: Petr Lautrbach <plautrba@redhat.com> > > > > Laurent, is it acceptable for Debian? > > Yes it's OK for debian as well. > > /run is a symlink to /var/run here too, see point 8 at > https://www.debian.org/doc/debian-policy/ch-opersys.html#file-system-hierarchy Thanks for checking this! Merged. Nicolas > > > > > >> --- > >> restorecond/restorecond.c | 4 ++-- > >> restorecond/restorecond.conf | 2 +- > >> restorecond/restorecond.init | 2 +- > >> restorecond/restorecond.service | 2 +- > >> restorecond/utmpwatcher.c | 2 +- > >> 5 files changed, 6 insertions(+), 6 deletions(-) > >> > >> diff --git a/restorecond/restorecond.c b/restorecond/restorecond.c > >> index 7b984b298f79..d5f70fc2e2c1 100644 > >> --- a/restorecond/restorecond.c > >> +++ b/restorecond/restorecond.c > >> @@ -84,7 +84,7 @@ static void done(void) { > >> selabel_close(r_opts.hnd); > >> } > >> > >> -static const char *pidfile = "/var/run/restorecond.pid"; > >> +static const char *pidfile = "/run/restorecond.pid"; > >> > >> static int write_pid_file(void) > >> { > >> @@ -217,7 +217,7 @@ int main(int argc, char **argv) > >> write_pid_file(); > >> > >> while (watch(master_fd, watch_file) == 0) { > >> - }; > >> + } > >> > >> watch_list_free(master_fd); > >> close(master_fd); > >> diff --git a/restorecond/restorecond.conf b/restorecond/restorecond.conf > >> index c64e74758d2f..1a61ece384d7 100644 > >> --- a/restorecond/restorecond.conf > >> +++ b/restorecond/restorecond.conf > >> @@ -2,7 +2,7 @@ > >> /etc/resolv.conf > >> /etc/samba/secrets.tdb > >> /etc/updatedb.conf > >> -/var/run/utmp > >> +/run/utmp > >> /var/log/wtmp > >> /root/* > >> /root/.ssh/* > >> diff --git a/restorecond/restorecond.init b/restorecond/restorecond.init > >> index 775c52b0ce7c..c1cbb247fa91 100644 > >> --- a/restorecond/restorecond.init > >> +++ b/restorecond/restorecond.init > >> @@ -9,7 +9,7 @@ > >> # > >> # processname: /usr/sbin/restorecond > >> # config: /etc/selinux/restorecond.conf -# pidfile: > >> /var/run/restorecond.pid > >> +# pidfile: /run/restorecond.pid > >> # > >> # Return values according to LSB for all commands but status: > >> # 0 - success > >> diff --git a/restorecond/restorecond.service > >> b/restorecond/restorecond.service > >> index 0511a1c740ac..6bce99d39735 100644 > >> --- a/restorecond/restorecond.service > >> +++ b/restorecond/restorecond.service > >> @@ -6,7 +6,7 @@ ConditionSecurity=selinux > >> [Service] > >> Type=forking > >> ExecStart=/usr/sbin/restorecond > >> -PIDFile=/var/run/restorecond.pid > >> +PIDFile=/run/restorecond.pid > >> > >> [Install] > >> WantedBy=multi-user.target > >> diff --git a/restorecond/utmpwatcher.c b/restorecond/utmpwatcher.c > >> index 62ad2e98aff3..8660520370de 100644 > >> --- a/restorecond/utmpwatcher.c > >> +++ b/restorecond/utmpwatcher.c > >> @@ -49,7 +49,7 @@ unsigned int utmpwatcher_handle(int inotify_fd, int > >> wd) > >> { > >> int changed = 0; > >> struct utmp u; > >> - const char *utmp_path = "/var/run/utmp"; > >> + const char *utmp_path = "/run/utmp"; > >> struct stringsList *prev_utmp_ptr = utmp_ptr; > >> if (wd != utmp_wd) > >> return -1; > >
On Thu, Mar 21, 2019 at 1:08 PM Dominick Grift <dac.override@gmail.com> wrote: > > Petr Lautrbach <plautrba@redhat.com> writes: > > > Nicolas Iooss <nicolas.iooss@m4x.org> writes: > > > >> On most distributions, /var/run is a symbolic link to /run so using > >> /var/run or /run lead to the same result. Nevertheless systemd > >> started > >> to warn about using /var/run in a service file, logging entries such > >> as: > >> > >> /usr/lib/systemd/system/restorecond.service:8: PIDFile= > >> references > >> path below legacy directory /var/run/, updating > >> /var/run/restorecond.pid → /run/restorecond.pid; please > >> update the > >> unit file accordingly. > >> > >> Switch to /run in order to follow this advice. > >> > >> Signed-off-by: Nicolas Iooss <nicolas.iooss@m4x.org> > > There are other occurances of "/var/run" tree-wide. Some more important > than others: cd selinux; grep -r "/var/run" . Are all distribution using /run instead of /var/run with a symlink from /var/run to /run? For me, it is all right to move a PID file, which is only shared between the service and the service manager, but moving files such as the Unix socket /var/run/setrans/.setrans-unix could cause issues on systems where /var/run and /run are different directories. Also, policycoreutils/scripts/fixfiles currently contains: find /var/run \( -context "*:${UNLABELED}*" -o -context "*:${UNDEFINED}*" \) -exec chcon --no-dereference --reference /var/run {} \; This command does not do anything useful when /var/run is a symlink (either a slash needs to be added to the path, in order to use /var/run, or /run needs to be specified too). Right now I do not have much time to investigate how several distributions configure their /run and /var/run directories (I am writing a research paper related to Dell's iDRAC system, which appears to be using SELinux since its version 9). If nobody else does this, I plan doing this work in April. Thanks, Nicolas
Nicolas Iooss <nicolas.iooss@m4x.org> writes: > On Thu, Mar 21, 2019 at 1:08 PM Dominick Grift <dac.override@gmail.com> wrote: >> >> Petr Lautrbach <plautrba@redhat.com> writes: >> >> > Nicolas Iooss <nicolas.iooss@m4x.org> writes: >> > >> >> On most distributions, /var/run is a symbolic link to /run so using >> >> /var/run or /run lead to the same result. Nevertheless systemd >> >> started >> >> to warn about using /var/run in a service file, logging entries such >> >> as: >> >> >> >> /usr/lib/systemd/system/restorecond.service:8: PIDFile= >> >> references >> >> path below legacy directory /var/run/, updating >> >> /var/run/restorecond.pid → /run/restorecond.pid; please >> >> update the >> >> unit file accordingly. >> >> >> >> Switch to /run in order to follow this advice. >> >> >> >> Signed-off-by: Nicolas Iooss <nicolas.iooss@m4x.org> >> >> There are other occurances of "/var/run" tree-wide. Some more important >> than others: cd selinux; grep -r "/var/run" . > > Are all distribution using /run instead of /var/run with a symlink > from /var/run to /run? For me, it is all right to move a PID file, > which is only shared between the service and the service manager, but > moving files such as the Unix socket /var/run/setrans/.setrans-unix > could cause issues on systems where /var/run and /run are different > directories. FHS still mentions /var/run, so i suppose from that perspective it should be supported. but using /var/run can slow down boot time plus lets say mcstrans would be socket activated, then we would need a fc spec for /var/run or else systemd would create the socket with a wrong label and then you get into a chicken and egg situation and we will still be using /var/run in the next decade. > > Also, policycoreutils/scripts/fixfiles currently contains: > > find /var/run \( -context "*:${UNLABELED}*" -o -context > "*:${UNDEFINED}*" \) -exec chcon --no-dereference --reference /var/run > {} \; > > This command does not do anything useful when /var/run is a symlink > (either a slash needs to be added to the path, in order to use > /var/run, or /run needs to be specified too). Right now I do not have > much time to investigate how several distributions configure their > /run and /var/run directories (I am writing a research paper related > to Dell's iDRAC system, which appears to be using SELinux since its > version 9). If nobody else does this, I plan doing this work in April. > > Thanks, > Nicolas >
diff --git a/restorecond/restorecond.c b/restorecond/restorecond.c index 7b984b298f79..d5f70fc2e2c1 100644 --- a/restorecond/restorecond.c +++ b/restorecond/restorecond.c @@ -84,7 +84,7 @@ static void done(void) { selabel_close(r_opts.hnd); } -static const char *pidfile = "/var/run/restorecond.pid"; +static const char *pidfile = "/run/restorecond.pid"; static int write_pid_file(void) { @@ -217,7 +217,7 @@ int main(int argc, char **argv) write_pid_file(); while (watch(master_fd, watch_file) == 0) { - }; + } watch_list_free(master_fd); close(master_fd); diff --git a/restorecond/restorecond.conf b/restorecond/restorecond.conf index c64e74758d2f..1a61ece384d7 100644 --- a/restorecond/restorecond.conf +++ b/restorecond/restorecond.conf @@ -2,7 +2,7 @@ /etc/resolv.conf /etc/samba/secrets.tdb /etc/updatedb.conf -/var/run/utmp +/run/utmp /var/log/wtmp /root/* /root/.ssh/* diff --git a/restorecond/restorecond.init b/restorecond/restorecond.init index 775c52b0ce7c..c1cbb247fa91 100644 --- a/restorecond/restorecond.init +++ b/restorecond/restorecond.init @@ -9,7 +9,7 @@ # # processname: /usr/sbin/restorecond # config: /etc/selinux/restorecond.conf -# pidfile: /var/run/restorecond.pid +# pidfile: /run/restorecond.pid # # Return values according to LSB for all commands but status: # 0 - success diff --git a/restorecond/restorecond.service b/restorecond/restorecond.service index 0511a1c740ac..6bce99d39735 100644 --- a/restorecond/restorecond.service +++ b/restorecond/restorecond.service @@ -6,7 +6,7 @@ ConditionSecurity=selinux [Service] Type=forking ExecStart=/usr/sbin/restorecond -PIDFile=/var/run/restorecond.pid +PIDFile=/run/restorecond.pid [Install] WantedBy=multi-user.target diff --git a/restorecond/utmpwatcher.c b/restorecond/utmpwatcher.c index 62ad2e98aff3..8660520370de 100644 --- a/restorecond/utmpwatcher.c +++ b/restorecond/utmpwatcher.c @@ -49,7 +49,7 @@ unsigned int utmpwatcher_handle(int inotify_fd, int wd) { int changed = 0; struct utmp u; - const char *utmp_path = "/var/run/utmp"; + const char *utmp_path = "/run/utmp"; struct stringsList *prev_utmp_ptr = utmp_ptr; if (wd != utmp_wd) return -1;
On most distributions, /var/run is a symbolic link to /run so using /var/run or /run lead to the same result. Nevertheless systemd started to warn about using /var/run in a service file, logging entries such as: /usr/lib/systemd/system/restorecond.service:8: PIDFile= references path below legacy directory /var/run/, updating /var/run/restorecond.pid → /run/restorecond.pid; please update the unit file accordingly. Switch to /run in order to follow this advice. Signed-off-by: Nicolas Iooss <nicolas.iooss@m4x.org> --- restorecond/restorecond.c | 4 ++-- restorecond/restorecond.conf | 2 +- restorecond/restorecond.init | 2 +- restorecond/restorecond.service | 2 +- restorecond/utmpwatcher.c | 2 +- 5 files changed, 6 insertions(+), 6 deletions(-)