Bug#857849: minidlna does not work if started via systemd
Hi Alexander, Thanks a million for the speedy response. After upgrading to the new version minidlna appears to function properly, so as far as I'm concerned this bug can be closed. Would the problem reappear I'll open another ticket. Once again, thanks so much for the prompt support. Cheers: --jtg *From:* Alexander Gerasiov *Sent:* Thursday, March 16, 2017 11:24 *To:* Jtg *Cc:* 857849 *Subject:* Re: Bug#857849: minidlna does not work if started via systemd Hello jtg, On Wed, 15 Mar 2017 18:07:44 +0100 jtg <deb...@jnet.hu> wrote: Package: minidlna Version: 1.1.5+dfsg-2~bpo8+1 Please check with 1.1.6, I've just uploaded backport into archive. Severity: grave I can't confirm this. On my box it worked on jessie from backports and right now it works on Stretch. So it's definitely not grave as not every user is affected. Justification: renders package unusable Dear Maintainer, I recently noticed that my minidlna server was unavalable, at least from VLC, even though it seemed to be running and I'm not aware of any changes directly related to minidlna. After some experimentation, I found that if started manually, with the exact same command line that systemd would use, it worked OK. Please check /var/log/minidlna.log and journalctl -u minidlna.service Is it fresh install or upgrade?
Bug#857849: minidlna does not work if started via systemd
Package: minidlna
Version: 1.1.5+dfsg-2~bpo8+1
Severity: grave
Justification: renders package unusable
Dear Maintainer,
I recently noticed that my minidlna server was unavalable, at least from VLC,
even though it seemed
to be running and I'm not aware of any changes directly related to minidlna.
After some
experimentation, I found that if started manually, with the exact same command
line that systemd
would use, it worked OK.
To be concrete, this invocation did not work:
# /etc/init.d/minidlna start
Starting minidlna (via systemctl): minidlna.service.
# pgrep minidlna|xargs ps
PID TTY STAT TIME COMMAND
13625 ?Ssl0:00 /usr/sbin/minidlnad -f /etc/minidlna.conf -P
/run/minidlna/minidlna.pid
whereas this did:
# /usr/sbin/minidlnad -f /etc/minidlna.conf -P /run/minidlna/minidlna.pid
# pgrep minidlna|xargs ps
PID TTY STAT TIME COMMAND
13674 ?Ssl0:00 /usr/sbin/minidlnad -f /etc/minidlna.conf -P
/run/minidlna/minidlna.pid
-- System Information:
Debian Release: 8.7
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 3.16.0-4-amd64 (SMP w/2 CPU cores)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)
Shell: /bin/sh linked to /bin/dash
Init: systemd (via /run/systemd/system)
Versions of packages minidlna depends on:
ii adduser 3.113+nmu3
ii libavformat566:11.8-1~deb8u1
ii libavutil54 6:11.8-1~deb8u1
ii libc62.19-18+deb8u7
ii libexif120.6.21-2
ii libflac8 1.3.0-3
ii libid3tag0 0.15.1b-11
ii libjpeg62-turbo 1:1.3.1-12
ii libogg0 1.3.2-1
ii libsqlite3-0 3.8.7.1-1+deb8u2
ii libvorbis0a 1.3.4-2
ii lsb-base 4.1+Debian13+nmu1
minidlna recommends no packages.
minidlna suggests no packages.
-- Configuration Files:
/etc/init.d/minidlna changed:
PATH=/sbin:/usr/sbin:/bin:/usr/bin
DESC="DLNA/UPnP-AV media server"
NAME=minidlna
DAEMON=/usr/sbin/minidlnad
PIDDIR=/run/$NAME
PIDFILE=$PIDDIR/$NAME.pid
SCRIPTNAME=/etc/init.d/$NAME
CONFIGFILE=/etc/minidlna.conf
LOGFILE=/var/log/minidlna.log
USER=minidlna
GROUP=minidlna
DAEMON_OPTS=""
[ -x "$DAEMON" ] || exit 0
[ -r /etc/default/$NAME ] && . /etc/default/$NAME
DAEMON_ARGS="-f $CONFIGFILE -P $PIDFILE $DAEMON_OPTS"
. /lib/init/vars.sh
. /lib/lsb/init-functions
export LANG=hu_HU.utf8
do_start()
{
# Return
# 0 if daemon has been started
# 1 if daemon was already running
# 2 if daemon could not be started
touch $LOGFILE && chown $USER:$GROUP $LOGFILE || return 2
mkdir -p $PIDDIR && chown $USER:$GROUP $PIDDIR || return 2
start-stop-daemon --start --quiet --pidfile $PIDFILE \
--chuid $USER:$GROUP --exec $DAEMON --test > /dev/null \
|| return 1
start-stop-daemon --start --quiet --pidfile $PIDFILE \
--chuid $USER:$GROUP --exec $DAEMON -- \
$DAEMON_ARGS \
|| return 2
}
do_stop()
{
# Return
# 0 if daemon has been stopped
# 1 if daemon was already stopped
# 2 if daemon could not be stopped
# other if a failure occurred
start-stop-daemon --stop --quiet --retry=TERM/30/KILL/5 --pidfile
$PIDFILE --exec $DAEMON
RETVAL="$?"
[ "$RETVAL" = 2 ] && return 2
# Wait for children to finish too if this is a daemon that forks
# and if the daemon is only ever run from this initscript.
start-stop-daemon --stop --quiet --oknodo --retry=0/30/KILL/5 --exec
$DAEMON
[ "$?" = 2 ] && return 2
# Many daemons don't delete their pidfiles when they exit.
rm -f $PIDFILE
return "$RETVAL"
}
do_rotate()
{
touch $LOGFILE && chown $USER:$GROUP $LOGFILE || return 2
start-stop-daemon --stop --signal USR2 --quiet --pidfile $PIDFILE
--exec $DAEMON
return 0
}
case "$1" in
start)
[ "$VERBOSE" != no ] && log_daemon_msg "Starting $DESC" "$NAME"
do_start
case "$?" in
0|1) [ "$VERBOSE" != no ] && log_end_msg 0 ;;
2) [ "$VERBOSE" != no ] && log_end_msg 1 ;;
esac
;;
stop)
[ "$VERBOSE" != no ] && log_daemon_msg "Stopping $DESC" "$NAME"
do_stop
case "$?" in
0|1) [ "$VERBOSE" != no ] && log_end_msg 0 ;;
2) [ "$VERBOSE" != no ] && log_end_msg 1 ;;
esac
;;
status)
status_of_proc "$DAEMON" "$NAME" && exit 0 || exit $?
;;
restart|force-reload)
log_daemon_msg "Restarting $DESC" "$NAME"
do_stop
case "$?" in
0|1)
if [ "$1" = "force-reload" ]; then
# Rescan the collection
DAEMON_ARGS="$DAEMON_ARGS -R"
fi
do_start
case "$?" in
0) log_end_msg 0 ;;
1) log_end_msg 1
Bug#702448: nfs-common: UID's do not get properly mapped
Package: nfs-common Version: 1:1.2.6-3 Severity: grave Tags: security Justification: user security hole Dear Maintainers, I've recetly set up an NFSv4 server and I found that ID mapping does always work as expected, allowing a user to read files they should not have access to (and preventing them to access files they should have access to). To demonstrate, I have set up a test NFS client and server pair, both running wheezy. I've created users test1 and test2 in /etc/passwd, but with swapped UID's: SERVER test1:x:5000:5000::/home/test1:/bin/bash test2:x:5001:5001::/home/test2:/bin/bash CLIENT test2:x:5000:5000::/home/test2:/bin/bash test1:x:5001:5001::/home/test1:/bin/bash On the server, I have /srv/nfs exported; the output of exportfs -a is: /srv/nfsworld To demonstrate the problem, I've crafted a script, which does the following: * creates a file on the client as user test1 (a); * created two files on the server, one as user test1 (b), one as user test2 (c); * runs ls -l on the files, both on the server and the client, to check the ownerships/permissions reported; * tries to read the files, both as user test1 and test2, both on the server and the client. What I've found is that * the file created on the client by user1 (a) shows up owned by user2 both on the server and the client -- BUG * the files created on the server (b and c) appear as expected both on the client and the server -- OK * on the client, user1 - can open the file created by user1 on the client (a) -- OK - cannot open the file created by user1 on the server (b) -- BUG - can open the file created by user2 on the server (c) -- SECURITY * on the client, user2 - cannot open the file created by user1 on client (a) -- OK - can open the file created by user1 on the server (b) -- SECURITY - cannot open the file created by user2 on the server (c) -- BUG * on the server, user1 - cannot open the file created by user1 on client (a) -- BUG - can open the file created by user1 on the server (b) -- OK - cannot open the file created by user2 on the server (c) -- OK * on the server, user2 - can open the file created by user1 on client (a) -- SECURITY - cannot open the file created by user1 on the server (b) -- OK - cannot open the file created by user2 on the server (c) -- OK The transscript and the debug output of rpc.idmapd on both the server and the client is attached. While my understanding of ID mapping is limited, I found it strange that according to the debug log, nfs4_name_to_uid doesn't get called on the client for user1 when creating the file. The transcript is the following: (NB: the script started on the client, and before it started, nfs-common was stopped on both client and server, there were no nfs mounts on the client, and the test directory was empty) # date Wed Mar 6 17:15:57 CET 2013 # SRV=192.168.56.102 # /etc/init.d/nfs-common start Starting NFS common utilities: statd idmapd. rpc.idmapd: libnfsidmap: using domain: localdomain rpc.idmapd: libnfsidmap: Realms list: 'LOCALDOMAIN' rpc.idmapd: libnfsidmap: loaded plugin /lib/i386-linux-gnu/libnfsidmap/nsswitch.so for method nsswitch # ssh $SRV /etc/init.d/nfs-common start Starting NFS common utilities: statd idmapd. rpc.idmapd: libnfsidmap: using domain: localdomain rpc.idmapd: libnfsidmap: Realms list: 'LOCALDOMAIN' rpc.idmapd: libnfsidmap: loaded plugin /lib/i386-linux-gnu/libnfsidmap/nsswitch.so for method nsswitch # mount $SRV:/ /mnt; mount -t nfs,nfs4 192.168.56.102:/ on /mnt type nfs4 (rw,relatime,vers=4,rsize=65536,wsize=65536,namlen=255,hard,proto=tcp,timeo=600,retrans=2,sec=sys,clientaddr=192.168.56.101,minorversion=0,local_lock=none,addr=192.168.56.102) # sudo -u test1 sh -c touch /mnt/srv/nfs/test/a; chmod 600 /mnt/srv/nfs/test/a # ssh $SRV sudo -u test1 touch /srv/nfs/test/b; chmod 600 /srv/nfs/test/b # ssh $SRV sudo -u test2 touch /srv/nfs/test/c; chmod 600 /srv/nfs/test/c # sleep 3; date Wed Mar 6 17:16:01 CET 2013 # ls --full-time /mnt/srv/nfs/test total 0 -rw--- 1 test2 test2 0 2013-03-06 17:15:58.0 +0100 a -rw--- 1 test1 test1 0 2013-03-06 17:15:58.0 +0100 b -rw--- 1 test2 test2 0 2013-03-06 17:15:58.0 +0100 c # ssh $SRV ls --full-time /srv/nfs/test total 0 -rw--- 1 test2 test2 0 2013-03-06 17:15:58.0 +0100 a -rw--- 1 test1 test1 0 2013-03-06 17:15:58.0 +0100 b -rw--- 1 test2 test2 0 2013-03-06 17:15:58.0 +0100 c # sudo -u test1 cat /mnt/srv/nfs/test/* cat: /mnt/srv/nfs/test/b: Permission denied # sudo -u test2 cat /mnt/srv/nfs/test/* cat: /mnt/srv/nfs/test/a: Permission denied cat: /mnt/srv/nfs/test/c: Permission denied # ssh $SRV sudo -u test1 cat
