Hey there. :) On 3/12/19 5:13 PM, jim_p wrote: > First of all, as soon as the package was updated to 1.4.3-2, I removed the > upstream udev rule and let it use the provided one. I see there is a small > difference between them, but I can not explain what that change actually does. > The problem is that that difference, imho, makes beep partialy broken.
The shipped udev rule is to allow local logged in users access to the device. Which is the common case, because you actually would want people in front of the computer to be able to beep it, others usually won't be able to hear it anyways. But yes, your case is something different, and for that the upstream suggested approach might be feasible. I though am not convinced that special casing for every corner cases of the usage of the package is the best move forward. It would add quite some complexity, and added dependency which I doubt that most people actually would benefit from. For those corner cases please create the beep group yourself and use the upstream suggested udev rule. Even if I would consider of adding the complexity needed for that (through facilitating debconf for questioning which kind of setup the admin would prefer) it would require testing and needs time to make sure it doesn't interfer with other things - and like said, would pull in another dependency. And given that we are now in freeze for buster time doesn't really permit that. If people have patches and merge requests that I could look at it might improve the chances for that to happen, but it still would be something for the next release. > p.s. mini rant: > I also noticed that the updated package still does not make the beep group, so > it is one more step for the user to do. The beep group would only be needed when doing the acl dance that upstream suggested. Given that we don't do that there is no need to create the group in the first place. > Other packages do that all the time (that's why I still have a debian-tor > group > although I have removed removed torbrowser ~2 years ago), so I don't think it > will be hard or pointless to have a beep group as well. Special groups are > mandatory for various reasons. The difference there is that torbrowser did actually use that group. Which the beep package never did. The older version of the package used the existing audio group, which made a fair amount of sense to facilitate for this. > And, because I had a small discussion about it with a fellow (and more > advanced) debian and beep user, if you consider a "security flaw" to have beep > running as a non-root user, why package beep at all? Plus, if I have to do all > that stuff by hand in order to make it "simply" work, why do I still have > debian and not gentoo (or arch at the very least)? Just because something might expose information in specific usage doesn't mean that it doesn't make sense for dedicated situations. I can't follow the reasoning that it would be beneficial to have it rather not at all than to have it available for a specific environment. I have no idea what you try to achieve with that kind of argumentation? And it *does* simply work. Just not for your special corner case, which is unfortunate, but that requires a bit more work. Depending on acl, creating a dedicated group and shipping a rule that facilitates that isn't that trivial to get right. Otherwise I would assume you had sent me already a patch for it, wouldn't you. :) Thanks for your interest in beep anyways, it's appreciated. Rhonda
