>May be so but this is allowed and getpwuid(geteuid()) will do the wrong
>thing for all but one login id sharing the same uid.
*shrug* I mean, yeah ... but so what? It's allowed, but we already
use getpwuid(getuid()) and we don't get bug reports on it being problem.
>Practically speaking,
On Jun 4, 2019, at 10:08 AM, Ken Hornstein wrote:
>> This fails when there are multiple users with the same uid as getpwuid()
>> will likely fetch the first matching entry. On FreeBSD (& May be other
>> BSDs) getlogin() is a syscall and works correctly without a controlling
>> terminal. But I
On Tue, 04 Jun 2019 13:08:43 -0400, Ken Hornstein said:
> True story: a long time ago we had a number of IRIX systems. The inetd
> on those systems was buggy so it was common when you changed the inetd
> configuration you just restarted it instead of sending it a HUP signal.
> But even though
>This fails when there are multiple users with the same uid as getpwuid()
>will likely fetch the first matching entry. On FreeBSD (& May be other
>BSDs) getlogin() is a syscall and works correctly without a controlling
>terminal. But I was forgetting about Linux which never disappoints
>in
On Jun 3, 2019, at 8:06 AM, Ken Hornstein wrote:
>
> I am thinking that falling back to getpwuid(getuid()) is the most reasonable
> approach, for the following reasons:
This fails when there are multiple users with the same uid as getpwuid()
will likely fetch the first matching entry. On
>> I am thinking that falling back to getpwuid(getuid()) is the most
>> reasonable approach
>
>I notice that a setuid inc(1) has various troubles due to the use of
>real user ID rather than effective.
Like ... what? I would have though using the real UID would have been the
correct answer.
Hi Ken,
> getusername() (the nmh function) is called by programs like slocal and
> rcvtty, which may not have a controlling terminal and I am unclear
> what LOGNAME would mean in their environment as well.
True. cron(8) here sets $LOGNAME, but does .forward, etc?
> I am thinking that falling
