----- Original Message -----
> On Wed, 09.07.14 12:25, Miloslav Trmač (mitr@xxxxxxxxxx) 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@xxxxxxxxxxxxxxxxxxxxxxx
https://admin.fedoraproject.org/mailman/listinfo/devel
Fedora Code of Conduct: http://fedoraproject.org/code-of-conduct
