On Mon, Apr 27 2020, Landry Breuil <landry@openbsd.org> wrote:
> On Mon, Apr 27, 2020 at 07:38:25AM +0200, Alexandre Ratchov wrote:
>> On Sun, Apr 26, 2020 at 08:40:08PM +0100, Stuart Henderson wrote:
>> >
>> > But....
>> >
>> > The problem with this is, on a multiuser system where you want to share
>> > audio between mpd (or audio/squeezelite, which has the same problem) and
>> > more than one user, you have to share a cookie between _mpd, user1 and
>> > user2, so sndiod's privacy mechanism is nullified.
>> >
>>
>> If mpd was allowed to bypass checks and play while either user1 or
>> user2 are using the device, the privacy mechanism would be affected
>> anyway. For instance user1 would be allowed to start music during
>> phone-calls of user2.
>>
>> > As an alternative, perhaps the mechanism sndiod now uses for root could be
>> > extended for users specified on sndiod's command line. Stupid hardcoded
>> > example for mpd, clearly not committable as-is, but demonstrating the concept.
>> >
>>
>> I'll try implement something like this, it's the safer.
>>
>> It would be nice if _mpd could start as root, open the device, drop
>> privileges then. I just tried it, but this fails because mpd calls
>> setuid() too early, probably not designed for this.
>>
>> The hack below makes mpd open the default device before main() is
>> called, then it reuses the same handle all the time. It works for me,
>> but if the device fails, mpd needs to be restarted; I don't know if
>> this is a problem, I don't use mpd very often.
>
> I like the idea (and this is probably how most openbsd daemons which do
> privdrop work) but this really should be brought up w/ upstream :)
> (which is friendly)
>
> as its an always-running daemon, having the device failing should be
> loud and clear so that the admin/user knows he has to restart, instead
> of silently dying or failing.. what could cause the device failing,
> sndiod dying ? plugging/unplugging a device ?
>
> Fwiw ive been using the var/spool/mpd hack with the aucat cookie
> sharing for many years, and yeah at some point it complained about perms
> but moving to 750 worked for me. Just had to copy the cookie once, so i
> dont think its a big deal to document it in mpd doc.
>
> drwxr-x--- 4 _mpd _mpd 512 Apr 11 09:24 /var/spool/mpd
> -rw------- 1 _mpd _mpd 16 Jan 16 2017 /var/spool/mpd/.aucat_cookie
> -rw------- 1 _mpd _mpd 16 Oct 12 2018 /var/spool/mpd/.sndio/cookie
>
> Im not sure we should address the 'many *real* users want to access
> sndiod' case. And adding a quirk to 'whitelist' a given user within
> sndiod feels a bit like a hidden knob...
I hate the idea of using the recently introduced root bypass for this.
Using root is a super big hammer, the bypass mechanism is young and
*maybe* fragile, it feels like it should stay a special case and
applications should not be redesigned around it. We're talking about
a media player here...
I'd rather have a documented option to whitelist application-specific
uids in sndiod. Maybe this doesn't need to be rushed before 6.7 though?
Regarding the initial proposal,
Christopher: indeed the home directory /var/spool/mpd with perms 770
would trigger security(8) warnings. I don't think those perms are
useful. And if they are (because people add users to the _mpd group)
then using /var/spool/mpd/home works around the security(8) warning but
doesn't fix the underlying issue (group write access over /var/spool/mpd
allows you to modify /var/spool/mpd/home). So the diff switches
/var/spool/mpd to 750; pkg_add -u updates the permissions.
(The diff also changes the perms of /var/log/mpd. and
/var/spool/mpd/playlists/, people can argue for specific perms if they
need them.)
Stuart: reusing your README proposal.
I just tried the sharing procedure (including the usermod step) on this
recently installed laptop, I can play sound both with mpd running as
_mpd and with mpv running as my regular uid.
So, what will it be?
Index: Makefile
===================================================================
RCS file: /cvs/ports/audio/mpd/Makefile,v
retrieving revision 1.129
diff -u -p -r1.129 Makefile
--- Makefile 27 Apr 2020 13:46:19 -0000 1.129
+++ Makefile 27 Apr 2020 14:08:37 -0000
@@ -3,7 +3,7 @@
BROKEN-hppa = no atomic ops
COMMENT = Music Player Daemon
VER = 0.21.21
-REVISION = 0
+REVISION = 1
DISTNAME = mpd-${VER}
EXTRACT_SUFX = .tar.xz
CATEGORIES = audio
Index: pkg/PLIST
===================================================================
RCS file: /cvs/ports/audio/mpd/pkg/PLIST,v
retrieving revision 1.13
diff -u -p -r1.13 PLIST
--- pkg/PLIST 15 Aug 2019 05:44:37 -0000 1.13
+++ pkg/PLIST 27 Apr 2020 14:08:37 -0000
@@ -1,7 +1,7 @@
@comment $OpenBSD: PLIST,v 1.13 2019/08/15 05:44:37 landry Exp $
@pkgpath audio/mpd,tremor
@newgroup _mpd:560
-@newuser _mpd:560:560:daemon:Music Player Daemon:/var/empty:/sbin/nologin
+@newuser _mpd:560:560:daemon:Music Player Daemon:/var/spool/mpd:/sbin/nologin
@extraunexec rm -rf /var/log/mpd/*
@extraunexec find /var/spool/mpd \! -name playlists -mindepth 1 -exec rm -rf "{}" \;
@rcscript ${RCDIR}/mpd
@@ -13,10 +13,11 @@ share/doc/mpd/AUTHORS
share/doc/mpd/COPYING
share/doc/mpd/NEWS
share/doc/mpd/README.md
+share/doc/pkg-readmes/${PKGSTEM}
share/examples/mpd/
share/examples/mpd/mpd.conf
@sample ${SYSCONFDIR}/mpd.conf
-@mode 770
+@mode 750
@owner _mpd
@group _mpd
@sample /var/log/mpd/
Index: pkg/README
===================================================================
RCS file: pkg/README
diff -N pkg/README
--- /dev/null 1 Jan 1970 00:00:00 -0000
+++ pkg/README 27 Apr 2020 14:08:37 -0000
@@ -0,0 +1,25 @@
+$OpenBSD: README.template,v 1.7 2019/05/09 17:45:05 ajacoutot Exp $
+
++-------------------------------------------------------------------------------
+| Running ${PKGSTEM} on OpenBSD
++-------------------------------------------------------------------------------
+
+sndiod(8) concurrent access by mpd(1) and other users
+=====================================================
+
+sndiod(8) normally only allows access to audio by a single system user
+at a time. This is done by generating a random authentication token and
+storing it in $HOME/.sndio/cookie when a user first accesses audio,
+providing a limited capability to share with other users by copying
+the token to their home directory. See AUTHENTICATION in sndio(7) for
+more details.
+
+If you want to share sndiod(8) access with mpd(1) running as the
+default _mpd user, you may copy .sndio/cookie from your user's home
+directory to /var/spool/mpd/.sndio/cookie.
+
+If you previously had mpd installed on your system, make sure the home
+directory of the _mpd user is actually /var/spool/mpd, or reset it
+with:
+
+# usermod -d /var/spool/mpd _mpd
--
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
No comments:
Post a Comment