RE: Bizarre setlogin propagation in 14.0/14.1

Yep, that squishes it in my test case. Shall I file a bug against calendar, or will this make its way in without such?

Thanks! It's amazing how easy it is to fix once you figure out the culprit...

Regards,

-- 
Steve Watt   KD6GGD     PP-ASEL-IA   factories.words.yappy
Don't let your schooling get in the way of your education.

-----Original Message-----
From: owner-freebsd-questions@FreeBSD.org <owner-freebsd-questions@FreeBSD.org> On Behalf Of Kyle Evans
Sent: Monday, July 22, 2024 21:24
To: questions@freebsd.org
Cc: Gleb Smirnoff <glebius@freebsd.org>
Subject: Re: Bizarre setlogin propagation in 14.0/14.1

On 7/22/24 23:01, Steve Watt wrote:
> Greetings,
> 
> I have been slowly chasing a very strange issue that’s been bugging me 
> since I upgraded to 14.0 (and now 14.1).
> 
> The presenting symptom was that the periodic daily and security runs 
> were appearing with random users as the envelope sender.
> 
> Much poking later (it takes a long time to run experiments if you want 
> to make sure they run in the real cron/periodic environment), I have 
> isolated it down to the daily/300.calendar, which several users on my 
> system use.
> 
> Somehow, it seems that the setusercontext call in calendar.c is … rather 
> effective. It appears to be setting the login ID for the parent process 
> somehow?
> 
> Easy-to-demonstrate sample:
> 
> (root@rivendell) 336# sh
> 
> # id -p
> 
> uid     root
> 
> groups  users wheel www vboxusers
> 
> # calendar -a
> 
> # id -p
> 
> login   jpick3543
> 
> uid     root
> 
> groups  users wheel www vboxusers
> 
> # exit
> 
> (root@rivendell) 337# id -p
> 
> login   jpick3543
> 
> uid     root
> 
> (root@rivendell) 338#
> 
> It’s been a lot of years since I dug deeply into a POSIX TTY subsystem 
> (I briefly worked on one for an RTOS in the mid-‘90s), but this behavior 
> is rather startling. It also seems to be different from at least 12.4, 
> which was the last production release I was running – I skipped 13.x.
> 
> Is this somehow expected behavior? Or is there some weird corner case 
> being worked over here?
> 

I don't think this is expected, but rather just an oversight.  `calendar 
-a` should almost certainly setsid() after fork() to avoid setlogin(2) 
clobbering the session login name for the caller.

diff --git a/usr.bin/calendar/calendar.c b/usr.bin/calendar/calendar.c
index 7610ad034759..e07dee52403e 100644
--- a/usr.bin/calendar/calendar.c
+++ b/usr.bin/calendar/calendar.c
@@ -209,6 +209,7 @@ main(int argc, char *argv[])
                         if (pid == 0) {
                                 login_cap_t *lc;

+                               setsid();
                                 lc = login_getpwclass(pw);
                                 if (setusercontext(lc, pw, pw->pw_uid,
                                     LOGIN_SETALL) != 0)