----- Original Message -----
> On Wed, 09.07.14 12:25, Miloslav Trmač (m...@redhat.com) wrote:
> > > Can you be more specific about the name validation?
> >
> > The binding maximum length constraint is from the utmp format
> > (UT_NAMESIZE - 1); LOGIN_NAME_MAX is an upper bound but not binding,
> > and this has already ended up in systemd-sysuser’s documentation
> > essentially promising to do the impossible/unsafe by using the
> > non-binding maximum length.
<snip>
> If 32chars as required by utmp is really the limit we should follow
> here, then I would really enjoy if we'd actually set LOGIN_NAME_MAX to
> the same value.

I agree that would be useful, but it would also break the glibc ABI I’m afraid 
(and undefining LOGIN_NAME_MAX to indicate that sysconf() should be used would 
break “only” the API).  Yeah, the utmp connection is apparently not obvious to 
many people.

> Hmm, it would be good btw, if libuser would actually use glibc APIs, for
> the precise reasons you are pointing out. As it appears though you
> reimplemented all those APIs for no reason...

For the excuse, I have inherited that code, and it is a part of the module API 
so not that attractive to just drop.  As for future plans, I’m not inclined to 
rewrite this just for fun, especially when this is all going away in a about a 
year.

> Oh, also, libuser is a glib API. Nothing against glibc, but for the
> low-level stuff we do that runs with nothing around we try to be OOM
> safe, and stuff...
I’m afraid the libuser’s ABI embeds a GLib dependency, so it won’t be removed; 
though recent-ish additions have added enough utility functions that many users 
of libuser don’t have to touch GLib themselves.

*shrug* OOM-safety in a non-daemon is not all that useful.  The right thing to 
do of course would be to use a way higher-level language that does 90% of what 
GLib does inherently as a part of the language instead of having to choose, and 
disagree about, a C utility library, but that’s where we are…
    Mirek
-- 
devel mailing list
devel@lists.fedoraproject.org
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct

Reply via email to