Svante Signell <svante.sign...@gmail.com> writes: > On Wed, 2014-12-03 at 16:55 +0000, Simon McVittie wrote: >> On 03/12/14 14:46, Svante Signell wrote:
>>> If more granularity is needed, what's hindering introduction of even >>> more groups: like an image group and splitting the fb0 to more devices? >>> Or even subdirectories like /dev/snd/* for audio etc. >> This does not actually solve the same problem as logind's "uaccess", or >> ConsoleKit's "udev ACL" (which was an older version of the same general >> idea): it just splits it up into a larger number of orthogonal instances >> of the same problem, which is that group membership makes a poor >> encoding for temporary permissions. > Have you ever heard about openafs? Yes (I was one of the developers for years), and I'd agree with the statement that group membership makes a poor encoding for temporary permissions. It's hard to clean up afterwards. What point were you trying to make by referencing OpenAFS? I don't see the relevance. If you're referring to the (broken) representation of PAGs as manufactured UNIX groups, that's exactly why we got rid of that on Linux in favor of using the keyring instead, since using groups caused all sorts of weird problems and issues. And that was with assigning a unique new GID for every session and never trying to use it for any actual group things on the local system. OpenAFS still generates the group since some stuff relies on it, but the primary representation of the PAG is now in the session keyring. The GID thing was always considered a hack in the OpenAFS development community. It was only used because we lacked a good alternative that more correctly represented that information. When NFSv4 development sparked the modern Linux keyring data model, we were delighted to switch (and then got very frustrated by the GPL-only tags on various keyring features, but that's another argument). -- Russ Allbery (r...@debian.org) <http://www.eyrie.org/~eagle/> -- 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/87fvct4r76....@hope.eyrie.org