Simon, Sort of, but not exactly. I have a fundamental disagreement with assigning LOCAL group memberships using a remote source. In fact, I think something like this should be DISALLOWED. I guess the best example for how I think it *should* work is how Windows does it:
There exists two remote groups by default: "Domain Users" and "Domain Admins". Remote users are a member of these groups. It is *impossible* to make a local user a memory of these groups. There is not only no UI for it, but programatic checks that ensure a proper path of trust. Each Windows machine contains two LOCAL groups by default: "Users" and "Administrators". The act of joining a computer to a domain (the process which ends up creating a remote account for the machine itself, and configuring the machine to trust the remote source to vouch for the identity of it's groups and users, adds the remote "Domain Users" group to the local "Users" group, and it adds the remote "Domain Administrators" group to the local "Administrators" group. Members of the "Users" group are allowed to login at the desktop. By virtue of recursive group membership, all members of "Domain Users" are thus allowed to login at the desktop. It is a very nice, very clean model. It puts the information that belongs on the client, on the client. It ensures that the domain does not alter local group memberships. Only the local machine is in charge of those. There is an explicite joining process that adds the remote group to the local group. The client does this. Now, the proposed solution to our problem in a LDAP setup is to add the remote user to the "cdrom" group, on the server. This has a number of actual real problems, along with breaking the clean model I would prefer. What if there is no "cdrom" group? What if the meaning of the "cdrom" group differs between clients? Not all clients will be Ubuntu. Does that mean I need to maintain seperate group lists for each distro? That's silly. What about "powerdev", "scanner", "admin", "plugdev", video", "dip", "audio", "floppy", "cdrom", "dialout", and "adm". I have to put each of these on the remote server? That's a silly burden. I'd rather have a remote "Ubuntu Users" group, and add that remote group to each local group, and have permissiosn flow that way. Yes, I know we don't support recursive groups yet. We should. If it's something that goes along with this bug report, maybe. Maybe not. Either way, we need simpler integration for "local device" permissions, as the bug title states. So, I disagree with both the suggest remedy, as well as with closing the bug. I also disagree with Martin calling my prefered setup "strange." -- Simpler integration for "local device" permissions https://bugs.launchpad.net/bugs/10225 You received this bug notification because you are a member of Ubuntu Bugs, which is a direct subscriber. -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
