MAXLOGNAME + /etc/group + chkgrp invalid character @

[Dan The Man]

On Tue, 8 Nov 2011, Chuck Swiger wrote:

> Hi--
>
> On Nov 8, 2011, at 4:32 PM, Dan The Man wrote:
>> On Tue, 8 Nov 2011, Chuck Swiger wrote:
>>> On Nov 8, 2011, at 3:47 PM, Dan The Man wrote:
>>>> In the daily cron "Daily run output" email always get the following:
>>>>
>>>> Verifying group file syntax:
>>>> chkgrp: /etc/group: line 3: '@' invalid character
>>>
>>> chkgrp expects group names to consist of characters in isalnum().
>>
>> K so thats a simple fix where it does that check.
>
> usr.sbin/chkgrp/chkgrp.c, line ~117:
>
>       for (cp = f[0] ; *cp ; cp++) {
>            if (!isalnum(*cp) && *cp != '.' && *cp != '_' && *cp != '-' &&
>                (cp > f[0] || *cp != '+')) {
>                warnx("%s: line %d: '%c' invalid character", gfn, n, *cp);
>                e++;
>            }
> 	}
>
> Add a "&& *cp != '@'" clause to the if statement.

It doesn't bother me enough to have to modify the if statement on every 
new buildworld(which I seem to be doing alot of lately), honestly that one 
email login in the group file is only 
email login that will ever touch an /etc file, rest is in database. I 
wouldn't personally add any email type logins to a base system directly.

>
>>>> Could we modify system to support email addresses as usernames.
>>>
>>> Sure, that's why FreeBSD comes with source code.
>>> You can modify anything you like.  :-)
>>>
>>> However, if you want to use a domain-aware login mechanism, Kerberos is in the base system, and SASL and LDAP are available in ports.  You're not going to break anything allowing "@" into the list of characters which pw(8) likes, but the flatfile passwd and group files are not hierarchical the way domain-aware network identity systems are.
>>>
>>> A secondary issue is that there is rarely a one-to-one relationship between email addresses and users; many email addresses are aliases which expand either to a different username, or even to multiple users.
>>
>> Wish you would elaborate abit more here, what I have found is email addresses tend to make the best usernames, people can remember them :)
>> They are unique, and you solve 2 problems right away:
>> a) they can actually remember their username
>> b) they aren't having to pick through a million different taken usernames
>> they have to pick on their own, which is frusterating way people often do signups.
>
> If you've got a database of millions of users, you're definitely functioning in a different realm than what /etc/passwd and /etc/group were designed for.  :-)
>

Well thats the idea right, unlimited growth but a central place to store 
everything for scalability purposes. Of course if you actually tried to 
login 1 million people to same machine, I am sure you would kill the I/O 
instantly :)

Basically approach I've been taking is central database that stores all 
users, any machine can be configured to not allow logins from anyone in 
database by just removing them from /etc/nsswitch.conf. You can control 
which of those million users can login to a certain machine by simply 
modifying the select statement to the database in the nss-database config 
file...all in all these changes take 2 seconds to change and makes things 
quite easy.


> Anyway, the idea is that you should be able to define multiple hierarchy levels for your identity database, which NIS+, NetInfo, Kerberos, and LDAP (kinda-sorta) can support.  This lets you define an identity either at the root level, which is visible everywhere, or in subdomains from root, which means the identity is valid only within that subdomain but not in other subdomains-- and "johndoe" in one subdomain can be entirely different than "johndoe" in some other domain.  (If you want "johndoe" the same everywhere, you'd define it at root instead.)
>
> That's just a bare-bones explanation, but a more complete one would likely approach book-length.  :-)

I'm sure it would make an interesting read, I try not to concern myself to 
much with mechanisms that would likely to take to long to respond if there 
were millions of users, working directly with mysql/postgres/oracle from 
getgo i think is safe.

Think its almost like an analogy to where you started off building your 
network code using something simple like select() then you kicked yourself 
in the ass after for not having used epoll() on linux or kqueue() on 
freebsd in an eventloop as your application got to many connections.

I do like your idea in a small office type setting though, definately 
wouldn't mind trying something like that here at home so I had a central 
way for all these development machines I got lieing around to have some 
central login place.

Found this an interesting read last night:
http://www.mrp3.com/windows-to-unix-samba.html
might be abit dated...



Dan.

--
Dan The Man
CTO/ Senior System Administrator
Websites, Domains and Everything else
http://www.SunSaturn.com
Email: Dan at SunSaturn.com


>
>>> You might not care, but don't be surprised if you find that folks aren't willing to adopt this change back into FreeBSD-- I've seen a few people wanting to increase MAXLOGNAME since 2003 or so.
>>
>> I've talked to many sys admins as well, that are all modifying the code to the kernel for a decade now on every new make buildworld, would be nice to see it mainstream.
>
> Sure, you can find examples or counterexamples if you look for 'em...
>
> Regards,
> -- 
> -Chuck
>
>