Unix group memberships?
Volker.Lendecke at SerNet.DE
Mon Nov 20 09:03:55 GMT 2006
Somehow I've lost your original mail, I had to grab it from
> - IIUC, the + qualifier without explicit group looks in
> Winbind groups, then in /etc/passwd, then in /etc/groups.
> Apparently, this effectively fails all logins if a user
> with the same name as the requested group is found.
> Question: is this behaviour intentional?
Yes, it is intentional. In this case, you would have to
prefix with "unix group\".
> - The & qualifier searches in NIS groups, + searches in
> Winbind and Unix groups, @ is the same as &+. It looks to
> me as if you're trying to discourage this @&+ syntax, and
> using explicit group name instead. Question: how does
> explicit group naming supports multiple group look up
> options? Because if I'm correct, there is a strong
> & - NIS only
> +"Unix Group\" - unix groups only
> ??????? - winbind only
> + - winbind and unix groups
> ??????? - NIS and winbind
> ??????? - NIS and unix groups
> @,&+,+& - All three
> I'm not sure if the unknown combinations make any sense,
> but would it be at least more logical, to either add more
> special qualifiers, f.ex, + is still unix users/groups
> strictly, and * is winbind, @ same as &*+ . Or, if it is
> indeed so that you're dissatisfied with @&+, clean up the
> explicit group syntax, so it doesn't contradict the @&+
> notation ( by contradiction I mean that in order to
> specify a group one has to prefix one of @&+, and then
> again specify the group name). In this case you probably
> need only @ to say 'this is group, not user', and possibly
> extend the group syntax to "Unix
Thinking a bit more about this I come to the conclusion that
probably this "&+@" hackery is completely obsolete now that
we can figure out in a well-determined way what kind of
object a name maps to. If "foo" maps to a user, then this
user is meant, if "foo" maps to a group, then that user is
the one. If you have the conflict case, explicitly prefix
"unix user/group". If winbind is asked, no conflict can
happen anyway, as Windows does not allow this kind of
conflict. The only thing that remains is the & prefix that
looks at NIS netgroups.
Just one thing to note: If you mention NIS, this means NIS
netgroups, not normal NIS /etc/group style groups. The
latter are subsumed under "Unix groups".
So if we agree that at some point in the future we can dump
NIS _netgroup_ support, then we can completely dump this +@&
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: not available
Url : http://lists.samba.org/archive/samba-technical/attachments/20061120/9fbb498c/attachment.bin
More information about the samba-technical