Hi Ken,
I think any two group-base aliases would have triggered it.
That probably depends on the implementation of getgrnam(3) and
getgrgid(3). Perhaps some didn't rely on gr_mem not changing. The
current nmh code doesn't keep using the results of one call whilst using
the results of the previous IIRC, so lack of re-entrancy doesn't matter?
POSIX states the caller shall not modify anything in the returned
struct, or what that points to, based on the 3p man pages here, and it's
that which is probably biting; libc is assuming we haven't diddled with
its gr_mem.
Fixing this should be relatively easy. But ... is this code useful,
now? With the encoding schemes that exist today, you might want to put
an = sign in an email address, and really, how often are you sending
email to a Unix group?
mh-alias(5) already says `foo: *' is deprecated and will be removed so
`=' could be added to that list. But should `+' remain or then be
deprecated too? I can see some might use `=foo', but they might get
bitten...
I thought mh-alias(5) was doing a poor job of what `=foo' does, so I
tried to follow the code. Here's my understanding.
`=foo' calls addgroup("foo"). addgroup() tries getgrnam("foo") and, on
failure, getgrid(atoi("foo")), the latter is undocumented. If neither
succeeds then an error is returned to the caller. That may be ignored
depending on the source of the `=foo'.
It then runs through the group's members and searches for each in the
`homehead' list, the "in-core" /etc/passwd. It does not call init_pw()
first so this list may be empty. If it finds a match then the user is
added to the alias, else the lack of a match is ignored. Then, even
though we've done that search, getpwnam() is called to look up the user
and if found then the user is added to the alias, and appended to the
`homehead' list even though it may have already been found therein.
Over time, `homehead' accumulates duplicates.
Let's say that group `foo' has user `bar' as its sole member. I use
`=foo' and it all works swimmingly. One day, user `xyzzy' is added to
the machine, and group `foo'. `=foo' now includes him, as designed, but
I already had a `xyzzy' alias, unrelated to this user, defined after
`=foo' and so my private email to internal users in group foo now skips
user `xyzzy' and is sent to my `xyzzy' alias instead. I didn't edit my
configuration files; someone else added a user to a group with a
username that happened to clash with one of my existing private aliases.
This suggests usernames expanded from a group should not undergo further
alias expansion! :-)
`+' calls addmember(); I note that does call init_pw().
I think if they're staying then a bit of thought in how they should work
sanely is needed, even if that's just documenting of their current
oddities, once they're figured out.
--
Cheers, Ralph.
https://plus.google.com/+RalphCorderoy
_______________________________________________
Nmh-workers mailing list
Nmh-workers(_at_)nongnu(_dot_)org
https://lists.nongnu.org/mailman/listinfo/nmh-workers