Re: [nmh-workers] I Could Have Sworn that the inc Command used to work.
>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, pretty much all the programs I have seen use >either $USER or $LOGNAME. I do not believe that the common practice is to use USER or LOGNAME. My informal survey is that using getpwuid(getuid()) is by far more common. --Ken -- nmh-workers https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [nmh-workers] I Could Have Sworn that the inc Command used to work.
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 was forgetting about Linux which never disappoints >> in disappointing. I think use of $LOGNAME as a fallback may be good >> enough. > > I have to say ... if you have multiple users with the same UID, you deserve > whatever breakage you get. According to POSIX: 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. > The getlogin() function shall return a pointer to a string > containing the user name associated by the login activity with > the controlling terminal of the current process. The next sentence in getlogin(3P) says this: If getlogin() returns a non-null pointer, then that pointer points to the name that the user logged in under, even if there are several login names with the same user ID. > Also, POSIX says about LOGNAME: > > The system shall initialize this variable at the time of login > to be the user's login name. > > I am unclear on what "login" means; does it apply when running as part > of a .forward file? When you have a controlling terminal, yes, that is > understood but I see no guarantees for other execution environments. Practically speaking, pretty much all the programs I have seen use either $USER or $LOGNAME. Cron automatically sets up LOGNAME, HOME, SHELL and PATH before invoking a user specific cron job. > 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 the person who did this had su'd to root, some of their > user environment variables were inherited by their root shell and then > inherited by inetd ... and those made it down into various daemons > spawned by inetd which caused a whole bunch of confusing behavior at > login time. We eventually figured that out and fixed everything, but it > just made me realize that depending on inherited environment variables > isn't always safe. If nmh already depended on LOGNAME or USER, then > I'd be fine with keeping that behavior but I just fear the unintended > consequences of making a significant change like this. Perhaps but most every program that cares already uses USER or LOGNAME. I would’ve preferred getlogin() but Linux. -- nmh-workers https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [nmh-workers] I Could Have Sworn that the inc Command used to work.
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 the person who did this had su'd to root, some of their > user environment variables were inherited by their root shell and then > inherited by inetd ... and those made it down into various daemons > spawned by inetd which caused a whole bunch of confusing behavior at > login time. This behavior wasn't limited to IRIX or inetd. It could bite you on anything that used sysvinit or other schemes that had /etc/rc*.d/S34foobar scripts, where 'service foobar restart' would run the script inline. One particularly difficult to debug issue was an occasional hang of one of our Oracle databases. Finally tracked it down to part of the nightly automation which did the backups - it would wait till it got an e-mail saying the *previous* night's backup ran so it was safe to re-use the checkpoint area for this night's backup. Worked fine till one day I restarted Legato Networker around 1PM - and from there on all the "Your backup completed" mails went out as valdis@backupserver rather than root@backupserver... Whoops. :) (And yes, I did convince the DBAs to come up with a less brittle way of doing their nightlies. :) pgpCP8YwXF5aX.pgp Description: PGP signature -- nmh-workers https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [nmh-workers] I Could Have Sworn that the inc Command used to work.
>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 disappointing. I think use of $LOGNAME as a fallback may be good >enough. I have to say ... if you have multiple users with the same UID, you deserve whatever breakage you get. According to POSIX: The getlogin() function shall return a pointer to a string containing the user name associated by the login activity with the controlling terminal of the current process. And getlogin() is allowed to return ENXIO if there is no controlling terminal. So while Linux's behavior may be undesirable in this case it is certainly permitted. Also, POSIX says about LOGNAME: The system shall initialize this variable at the time of login to be the user's login name. I am unclear on what "login" means; does it apply when running as part of a .forward file? When you have a controlling terminal, yes, that is understood but I see no guarantees for other execution environments. 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 the person who did this had su'd to root, some of their user environment variables were inherited by their root shell and then inherited by inetd ... and those made it down into various daemons spawned by inetd which caused a whole bunch of confusing behavior at login time. We eventually figured that out and fixed everything, but it just made me realize that depending on inherited environment variables isn't always safe. If nmh already depended on LOGNAME or USER, then I'd be fine with keeping that behavior but I just fear the unintended consequences of making a significant change like this. --Ken -- nmh-workers https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [nmh-workers] I Could Have Sworn that the inc Command used to work.
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 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 disappointing. I think use of $LOGNAME as a fallback may be good enough. -- nmh-workers https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [nmh-workers] I Could Have Sworn that the inc Command used to work.
>> 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. Also, I didn't even think we supported that; at most we support setgid to the mail group (and it's a huge pile of code which I personally would love to get rid of). --Ken -- nmh-workers https://lists.nongnu.org/mailman/listinfo/nmh-workers
Re: [nmh-workers] I Could Have Sworn that the inc Command used to work.
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 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. So if the code stays as if then the documentation could do with clarifying. I'll make a note. -- Cheers, Ralph. -- nmh-workers https://lists.nongnu.org/mailman/listinfo/nmh-workers
