3 ms·
Drivers can be whatever but their effect is usually global not for a specific user or app. So when you update, say, a graphics driver you are updating a shared
by cruffle_duffle 2y ago
Drivers can be whatever but their effect is usually global not for a specific user or app. So when you update, say, a graphics driver you are updating a shared resource used by everything in the system.
You can run that display driver in whatever security context you want be it “root” or its own constrained context but that doesn’t change the fact that other things in the system, running under their own security contexts, are feeding that driver stuff. And given there is generally only one display output, or sound output, or whatever, all things in the system have to use it for output, making it more privileged than the rest.
Whatever security context a display driver runs in, that context by requirement has to be more privileged than whatever context your browser or a calculator app runs in. To make changes to that shared display driver, you need to cross some kind of security boundary and it would be nice to make sure the user is who they say they are, they are allowed to do the requested action and they are made aware of the change. Thus methods like UAC and sudo.
I’m not sure how you can escape that. Removing sudo and UAC doesn’t change the fact that something wants to mess with a shared resource running with some kind of elevated privilege.
- anthk 2y agoCheck Hurd's daemons and Plan9/9front (and Hurd's) namespaces.
- deleted 2y ago[deleted]
- deleted 2y ago[deleted]
- ruthmarx 2y ago> Thus methods like UAC and sudo. UAC and Sudo are pretty different when you actually compare their implementations and not just purpose. Sudo is just a text prompt, UAC's design includes an entire isolated desktop to ensure fake prompts and such can't happen.