Bug#923478: initscripts use unsafe `: >` shell command to create files

[Cristian Ionescu-Idbohrn]

On Sun, 14 Apr 2019, Dmitry Bogatov wrote:
> 
> Definitely. But default one is from bin:util-linux.

On my sid/unstable:

# dpkg -S /bin/login
login: /bin/login

# dpkg -s login
Package: login
Essential: yes
Status: install ok installed
Priority: required
Section: admin
Installed-Size: 2695
Maintainer: Shadow package maintainers 
<pkg-shadow-devel at lists.alioth.debian.org>
Architecture: amd64
Source: shadow
Version: 1:4.5-1.1

> I just did some testing on my virtual machine of Debian 9 (stable):
> 
>  * I logged in as root on tty1, deleted /var/run/utmp and tried to login
>    on tty2. I succeed to login as both root and non-root.
> 
>  * I commented out from bootmisc.sh all code, that works with
>    /var/run/utmp and rebooted. There were no errors, and I logged in
>    just fine.
> 
>    Something already created /var/run/utmp root:root, 644.
> 
> So I question, how much of this code is actually necessary:
> 
>  * group 'utmp' exists on bare system, so conditional is not needed.
>  * if /var/run/utmp is missing, nothing bad seems to happen, so does
>    this code is needed at all?
> 
> Opinions?

IMO, less code is better.  I didn't loog at the source.  But I can 
see this:

# strings /bin/login | egrep 'utmp|faillog|/'
/lib64/ld-linux-x86-64.so.2
/usr/share/locale
No utmp entry.  You must exec "login" from the lowest level "sh"
/var/log/faillog
Can't write faillog entry for UID %lu in %s.
Can't open the faillog file (%s) to check UID %lu. User access 
authorized.
Can't reset faillog entry for UID %lu in %s.
PATH=/bin:/usr/bin
PATH=/sbin:/bin:/usr/sbin:/usr/bin
No directory, logging in with HOME=/
/bin/sh
/dev/%s
utmp.c
/dev/
setutmp
prepare_utmp
/etc/gshadow
/bin/sh
/etc/login.defs

> PS. Cristian, it seems I did not enough research prior asking you to
>     make patch and caused labour wasted. I am sorry.

No worries.  Still, I would be cautious.  That redirection (with or 
without a command prefix) is still questionable, as it _truncates_ the 
file (as opposed to just touching it).


Cheers,

-- 
Cristian