>>>>> Josselin Mouette <j...@debian.org> writes:
>>>>> Le dimanche 30 novembre 2014 à 12:50 +0000, Ivan Shmakov a écrit :
[…]
>> For home installs, I see no reason for the owner of the device to be
>> /denied/ access to the sound card just because of using SSH. Why,
>> it’s exactly what I do. (I even did things like $ ssh remote
>> ogg123 /dev/stdin < local/file.ogg for various reasons in the past.)
> PolicyKit does not control access to devices. The case you pointed
> out is already handled correctly by systemd:
> * Users needing full access can be added to the audio group.
Good to know the support for such groups isn’t going to be
dropped anytime soon. (Along with, say, SysVinit support.)
> * Other users only have access to audio devices through ACLs when
> physically logged on.
Unless I be mistaken, ACLs are only applied at the time of
open(2). What about the processes (if any) which opened an
audio device back when it was possible, but are still running at
the time the user logs out?
>> OTOH, for “workplace” installs, I see no reason for the user to be
>> /granted/ access to the things like network management just because
>> he or she happens to be logged in locally, – these privileges should
>> rather be granted only to the person(s) responsible for that
>> particular host. (And then again, – SSH is a perfectly valid way to
>> access to these facilities.)
> The nice thing about PolicyKit is that it is configurable. In this
> case, you might want to ship laptops to your users and still allow
> them to switch wifi networks without giving them root access.
Doesn’t “physical access” generally imply “root access”? At the
very least, it /used/ to be, and if it still is, I’d rather
consider the above a mere inconvenience rather that a security
feature.
> But in the general case, there are things that make sense to forbid
> in a workplace environment. It just takes a PKLA file to do so.
You’ve mentioned “the principle of least privilege” below; if I
understand your comment there correctly, doesn’t that also mean
that access to, say, network configuration should actually be
explicitly /granted/ (rather than explicitly forbidden)?
>> IIRC, D-I used to add the first non-root user it creates (which more
>> or less is bound to happen to be the owner, or the person otherwise
>> responsible for the host) to a number of groups (like audio or
>> plugdev) to grant access to certain devices. I know of no reason to
>> abandon this practice.
> This practice is still here, but it is absurd.
Actually, I have no strong preference on this issue. I tend to
use a full-weight Debian system when installing Debian (that is:
# debootstrap … /mnt) whenever possible, which happens to be
almost every time. Hence, I use D-I only occasionally.
Still, if that’s a bug, could you please provide examples of the
categories of users affected?
> It makes the first user created special for no reason,
I guess the reason is that that user is going to be either the
owner for the system, or the person responsible for installing
Debian there. Why, I seriously doubt that the D-I user would
create an account for some random person at that point.
> failing the principle of least privilege. If you need permanent
> access to this device or that feature for a given user, you can add
> it to the required groups only if needed.
Yes.
--
FSF associate member #7257 np. Coming Home — Iron Maiden 3013 B6A0 230E 334A
--
To UNSUBSCRIBE, email to debian-devel-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive: https://lists.debian.org/87r3wkmykq....@violet.siamics.net
