On Thu, Feb 05, 2009 at 11:25:31PM -0800, Aaron Stellman wrote: > mpd port creates "_mpd" user and example config suggest to use it. > Recent changes to aucat introduce some problems for mpd and possibly for > other audio ports that run as a separate user. mpd process > tries to connect to /tmp/aucat-560/default and fails. 560 being uid for > _mpd. > Ideally, this needs to be documented and fixed. > thanks
"fixed", heh. you do realize that is was possible for any user to eavesdrop e.g. VoIP sessions, right? not only intentional recordings, but really anything going on around the machine. don't forget that most laptops have built-in microphones. that's the reason for the access restrictions we have now. imo, mpd running as it's own user on a machine that has only one real user introduces security problems. yep, chrooting and dropping privileges can be bad for security, because it makes other things more complicated. if there is only one user who will ever use mpd on a machine, just run mpd as that user, and make sure noone else can access mpd. why does mpd run as it's own user? because it could be comprimised and an attacker could start executing commands as _mpd. so does it make sense to let _mpd access aucat, which could let the attacker eavesdrop? not to me it doesn't. better to close off access to mpd instead of assuming that chroot/privdrop is a magic bullet, imo. or, if mpd is being employed to make a machine a "juke box", where there will be no recording *at all* (don't forget about built-in mics on laptops), then run aucat as _mpd. if your situation doesn't fit either of those admittedly black/white extremes, then things get much more complicated. it's not easy to implement an effective works-and-is-secure-by-default and works-in-any-situation solution, but we're working on it. -- [email protected] SDF Public Access UNIX System - http://sdf.lonestar.org
