calendar: don't setlogin(2) in the -a user handlers

[kevans]

Summary

As of e67975d331 ("Fix 'calendar -a' in several ways."), calendar -a
will now fork off a new process for each user and do all of its own
processing in the user's own context.

As a side-effect, calendar(1) started calling setlogin(2) in each of the
forked processes and inadvertently hijacked the login name for the
session it was running under, which was typically not a fresh session
but rather that of whatever cron/periodic run spawned it. Thus, daily
and security e-mails started coming from completely arbitrary user.

We could create a new session, but it appears that nothing calendar(1)
does really needs the login name to be clobbered; opt to just avoid the
setlogin(2) call entirely rather than incur the overhead of a new
session for each process.

PR: 280418
Fixes: e67975d331 ("Fix 'calendar -a' in several ways.")

[olce]

These calls are arguably not necessary.

But IMO the real bug is, and always has been in situations like this, that a setlogin() call should never succeed except for session leaders. Would you recall any reason for the current setlogin()'s behavior?

[kevans]

In D46095#1051560, @olce wrote:

These calls are arguably not necessary.

But IMO the real bug is, and always has been in situations like this, that a setlogin() call should never succeed except for session leaders. Would you recall any reason for the current setlogin()'s behavior?

I traced the documentation of it in setlogin(2) back to 574317c8f182e3443 in 1996 by @peter where he notes:

The most notable offender of setlogin() misuse is XFree86's xdm.

I've no idea if the situation has improved since then. Maybe @kib has an opinion, too.