One of\u00a0the\u00a0more curious problems of\u00a0running Linux on\u00a0desktops is\u00a0handling the\u00a0local device access. The\u00a0idea is\u00a0usually quite simple: local users should have access to\u00a0devices such as\u00a0removable media (floppies, pendrives), scanners, speakers, webcams and\u00a0ability to\u00a0power off or\u00a0reboot the\u00a0computer. At\u00a0the\u00a0same time, remote users should have that access restricted.<\/p>\n
Why? I think the\u00a0main rationale behind this is\u00a0that those users have physical access to\u00a0those functions (yes, you could say that they have physical hard drive access too). They can insert the\u00a0floppies, plug the\u00a0pendrive, press the\u00a0power button or\u00a0just pull out the\u00a0plug. They usually suffer the\u00a0speaker noises and\u00a0scare in\u00a0front of\u00a0the\u00a0webcam.<\/p>\n
At\u00a0the\u00a0same time, remote (or\u00a0inactive users) shouldn’t be\u00a0given the\u00a0right to shut down the\u00a0system unexpectedly, shout into\u00a0the\u00a0speakers, stream the\u00a0user’s webcam or\u00a0install Windows to\u00a0his pendrive. I think that doesn’t need explaining.<\/p>\n
I would like to\u00a0shortly describe a\u00a0few attempts to\u00a0solve the\u00a0problem and\u00a0the\u00a0issues with\u00a0them.<\/p>\n
<\/p>\n
The\u00a0simplest solution is to give users unlimited access to the\u00a0listed resources. However, this only satisfies one of\u00a0the\u00a0goals and\u00a0therefore can work only in\u00a0pure single-user environment.<\/p>\n
This solution is\u00a0based on\u00a0standard *nix access management. The\u00a0relevant devices are owned by\u00a0a\u00a0dedicated group or\u00a0groups (like Sadly, this solution has more disadvantages than\u00a0advantages. The\u00a0access assignments are\u00a0basically static. Each user needs be\u00a0given access explicitly, and\u00a0retains it throughout local and\u00a0remote sessions.<\/p>\n In\u00a0fact, this is an\u00a0acceptable solution for\u00a0a\u00a0single-local-user system. Assuming that all other users are\u00a0remote users, we can safely grant full access to the\u00a0only user that is supposed to be\u00a0able to use the\u00a0machine locally (he’s most likely got root access too).<\/p>\n What if\u00a0we could dynamically add users to\u00a0the\u00a0 In\u00a0this case, the\u00a0access to\u00a0the\u00a0relevant groups is\u00a0given for local logins in\u00a0form of\u00a0supplementary groups for\u00a0the\u00a0process (session). That is, the\u00a0user who logged in locally implicitly belongs to the\u00a0groups and\u00a0the\u00a0same user logged in remotely doesn’t have access to\u00a0the\u00a0devices \u2014 even if\u00a0both sessions are\u00a0active simultaneously.<\/p>\n While this seems near to\u00a0perfect, it\u00a0has two disadvantages. First of\u00a0them is\u00a0spelled out on\u00a0top of\u00a0the\u00a0manpage and\u00a0configuration file: if\u00a0user can create a\u00a0setgid executable, he\u00a0can use it to\u00a0acquire a\u00a0persistent access to\u00a0the\u00a0groups independent of\u00a0the\u00a0location. Therefore, the\u00a0solution is\u00a0only beneficial when users are restricted from\u00a0running their own executables.<\/p>\n The\u00a0other problem is\u00a0that multiple local sessions are\u00a0given equal access to\u00a0the\u00a0devices. That is, if\u00a0one\u00a0user locks out his session and\u00a0the\u00a0other logs in, the\u00a0locked session can still use (and\u00a0block) all\u00a0the\u00a0devices.<\/p>\n The\u00a0most recent attempt at\u00a0solving the\u00a0issue completely has taken the\u00a0form of\u00a0ConsoleKit<\/a> and\u00a0systemd\/logind<\/a>. They’re both poorly documented but\u00a0I’ll try to\u00a0make most of\u00a0them.<\/p>\n The\u00a0basic idea is\u00a0that there is\u00a0a\u00a0daemon that tracks user logins (seats). The\u00a0daemon is\u00a0responsible for\u00a0complete control of\u00a0device permissions and\u00a0action access based on\u00a0logged\u00a0in users and\u00a0the\u00a0active session.<\/p>\n That said, the\u00a0solution is the\u00a0most flexible and\u00a0secure one. With the\u00a0use of\u00a0ACLs on\u00a0devices and\u00a0abstraction over power actions, the\u00a0users can be\u00a0given minimal permissions necessary. You could say that it can solve all the\u00a0problems. Plus achieve even more, like blocking shutdown actions while writing CDs.<\/p>\n However, there’s one simple problem. They are not really well documented. The\u00a0former is\u00a0supposedly unmaintained, the\u00a0latter is\u00a0tightly bound to\u00a0systemd and\u00a0far from\u00a0being portable. Upstream seems to be\u00a0focusing on\u00a0telling others how to\u00a0write different kinds of\u00a0applications rather than\u00a0documented what they have written.<\/p>\n Therefore, most of\u00a0the\u00a0information in\u00a0this section is\u00a0either discovered or\u00a0guessed. I haven’t seen a\u00a0comparison of\u00a0ConsoleKit with\u00a0logind either.<\/p>\n Honestly? I have no\u00a0idea what the\u00a0future would look like. Some developers are working on\u00a0running logind without systemd \u2014 but that looks like tilting at\u00a0windmills to\u00a0me. It may help for a\u00a0while but\u00a0the\u00a0number of\u00a0issues will grow over time, and\u00a0it still won’t help on\u00a0systems which are not\u00a0modern GNU\/Linux.<\/p>\n The\u00a0other solution is to\u00a0revive ConsoleKit. However, it will need to grow a\u00a0logind-compatible interface or\u00a0otherwise it won’t be\u00a0useful for\u00a0systemd purists like GNOME, and\u00a0possibly a\u00a0more modern Linux backend utilizing cgroups.<\/p>\n Curious enough, the\u00a0\u00abtiny daemon\u00bb of\u00a0logind has a\u00a0similar amount of\u00a0code as\u00a0the\u00a0whole ConsoleKit, even though ConsoleKit supports larger number of\u00a0platforms and\u00a0logind heavily relies on\u00a0other components of\u00a0systemd doing the\u00a0right thing\u2122.<\/p>\n","protected":false},"excerpt":{"rendered":" One of\u00a0the\u00a0more curious problems of\u00a0running Linux on\u00a0desktops is\u00a0handling the\u00a0local device access. The\u00a0idea is\u00a0usually quite simple: local users should have access to\u00a0devices such as\u00a0removable media (floppies, pendrives), scanners, speakers, webcams and\u00a0ability to\u00a0power off or\u00a0reboot the\u00a0computer. At\u00a0the\u00a0same time, remote users should have that access restricted. Why? I think the\u00a0main rationale behind this is\u00a0that those users have physical … Continue reading “Local device access \u2014 from\u00a0plugdev to\u00a0logind”<\/span><\/a><\/p>\n","protected":false},"author":137,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"jetpack_publicize_message":"","jetpack_is_tweetstorm":false,"jetpack_publicize_feature_enabled":true},"categories":[3],"tags":[],"jetpack_publicize_connections":[],"jetpack_featured_media_url":"","_links":{"self":[{"href":"https:\/\/blogs.gentoo.org\/mgorny\/wp-json\/wp\/v2\/posts\/193"}],"collection":[{"href":"https:\/\/blogs.gentoo.org\/mgorny\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/blogs.gentoo.org\/mgorny\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/blogs.gentoo.org\/mgorny\/wp-json\/wp\/v2\/users\/137"}],"replies":[{"embeddable":true,"href":"https:\/\/blogs.gentoo.org\/mgorny\/wp-json\/wp\/v2\/comments?post=193"}],"version-history":[{"count":10,"href":"https:\/\/blogs.gentoo.org\/mgorny\/wp-json\/wp\/v2\/posts\/193\/revisions"}],"predecessor-version":[{"id":203,"href":"https:\/\/blogs.gentoo.org\/mgorny\/wp-json\/wp\/v2\/posts\/193\/revisions\/203"}],"wp:attachment":[{"href":"https:\/\/blogs.gentoo.org\/mgorny\/wp-json\/wp\/v2\/media?parent=193"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/blogs.gentoo.org\/mgorny\/wp-json\/wp\/v2\/categories?post=193"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/blogs.gentoo.org\/mgorny\/wp-json\/wp\/v2\/tags?post=193"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}plugdev<\/code>, usb<\/code>, video<\/code>\u2026) and\u00a0therefore can only be\u00a0used by\u00a0users belonging to\u00a0those groups.<\/p>\nDynamic groups via\u00a0pam_group<\/h2>\n
plugdev<\/code> group (and\u00a0similar) whenever they log in locally? This is\u00a0basically the\u00a0solution which can be\u00a0achieved with the\u00a0help of\u00a0pam_group<\/code> module.<\/p>\nDynamic permissions via\u00a0ConsoleKit and\u00a0logind<\/h2>\n
The future?<\/h2>\n