[v2] cuserid: support invocation with a NULL pointer argument

Submitted by Sören Tempel on Jan. 29, 2020, 11:20 a.m.

Details

Message ID 20200129112007.17575-1-soeren+git@soeren-tempel.net
State New
Series "cuserid: support invocation with a NULL pointer argument"
Headers show

Commit Message

Sören Tempel Jan. 29, 2020, 11:20 a.m.
I did not manage to find a copy of IEEE 1003.1-1988 (the last POSIX
version where cuserid was last standardized) the Single UNIX
specification version 2 does state the following though [1]:

	If s is a null pointer, this representation is generated in an
	area that may be static (and thus overwritten by subsequent
	calls to cuserid()), the address of which is returned.

Even though this a legacy function it would therefore be nice for musl
to support usage with a NULL pointer. I ran into this on Alpine Linux
when using cdparanoia [2] which uses cuserid like this and therefore
caused a crash on my system.

[1]: https://pubs.opengroup.org/onlinepubs/7908799/xsh/cuserid.html
[2]: https://xiph.org/paranoia/index.html
---
 src/legacy/cuserid.c | 2 ++
 1 file changed, 2 insertions(+)

Patch hide | download patch | download mbox

diff --git a/src/legacy/cuserid.c b/src/legacy/cuserid.c
index 4e78798d..fd7832e4 100644
--- a/src/legacy/cuserid.c
+++ b/src/legacy/cuserid.c
@@ -5,10 +5,12 @@ 
 
 char *cuserid(char *buf)
 {
+	static char usridbuf[L_cuserid];
 	struct passwd pw, *ppw;
 	long pwb[256];
 	if (getpwuid_r(geteuid(), &pw, (void *)pwb, sizeof pwb, &ppw))
 		return 0;
+	if (!buf) buf = usridbuf;
 	snprintf(buf, L_cuserid, "%s", pw.pw_name);
 	return buf;
 }

Comments

Sören Tempel Jan. 29, 2020, 11:59 a.m.
Sorry, forgot to confirm my list subscription before sending the first
version of this patch. Just wanted to reply to a comment on the previous
version:

On Tue, 28 Jan 2020, Rich Felker wrote:
> I'm not sure whether to adopt this or not, but thanks for posting on
> the list for discussion. In any case it's something we should try to
> get fixed in apps that are using it, since this is no longer portable
> usage and is gratuitously thread-unsafe.

From my personal Alpine Linux packaging perspective: I would prefer
either removing the function entirely or supporting the invocation with
a NULL pointer argument. Currently, apps using this with a NULL pointer
(e.g. cdparanoia) will crash at runtime which makes it more difficult to
identify them. If the function would be removed entirely we would be
able to detect, during compilation, which apps use it and patch them
accordingly.

Cheers,
Sören
Sören Tempel March 22, 2020, 9:51 a.m.
Sören Tempel <soeren@soeren-tempel.net> wrote:
> From my personal Alpine Linux packaging perspective: I would prefer
> either removing the function entirely or supporting the invocation with
> a NULL pointer argument. Currently, apps using this with a NULL pointer
> (e.g. cdparanoia) will crash at runtime which makes it more difficult to
> identify them. If the function would be removed entirely we would be
> able to detect, during compilation, which apps use it and patch them
> accordingly.

Ping.

Greetings,
Sören
Rich Felker March 22, 2020, 3:05 p.m.
On Sun, Mar 22, 2020 at 10:51:56AM +0100, Sören Tempel wrote:
> Sören Tempel <soeren@soeren-tempel.net> wrote:
> > From my personal Alpine Linux packaging perspective: I would prefer
> > either removing the function entirely or supporting the invocation with
> > a NULL pointer argument. Currently, apps using this with a NULL pointer
> > (e.g. cdparanoia) will crash at runtime which makes it more difficult to
> > identify them. If the function would be removed entirely we would be
> > able to detect, during compilation, which apps use it and patch them
> > accordingly.
> 
> Ping.

Thanks. I'm trying to catch up on patches and I just confirmed your
research, so I think the patch is correct. I'll apply soon.

Rich