Messages from cron / perodic show up as random users

S

SteveW

OK, this one's really quite strange. I've been using FreeBSD for rather a long time (2.x-ish). In mid December I upgraded my 12.4-RELEASE system to 14.0-RELEASE.

Since then, the mails generated by periodic's daily and security runs have shown up in my mailbox with a variety of users as the sender. I've seen legit user accounts as well as system accounts (MySQL, ACME, etc.).

The oddest part of all is that the weeklies correctly show up as Charlie Root.

I'm quite baffled. Poking around in logs hasn't given me any clues.

Looking for ideas how to troubleshoot this one.
 
I ran mergemaster as part of the upgrade process; rather assumed it DTRT. I just manually did a vipw with a minor change to force a new update. Shall see when tonight's run happens.
 
That's quite perplexing. It still feels like you have database corruption. Does any account other than root and toor have a uid of zero? Have a close look at the output from:
Code: 
sudo cut -d: -f3,8 /etc/master.passwd  | sort -n
It's probably also time to eliminate the unlikely causes. Reboot. Check the file systems...
 
Let's see...

Code: 
 20# cut -d: -f3,8 /etc/master.passwd  | sort -n
0:Bourne-again Superuser
0:Charlie &
1:Owner of many system processes
2:System &
3:Binaries Commands and Source
4:Tty Sandbox
5:KMem Sandbox
7:Games pseudo-user
8:News Subsystem
9:Mister Man Pages
22:Secure Shell Daemon
25:Sendmail Submission User
[ ... ]
 21# rm /etc/spwd.db /etc/pwd.db
 22# pwd_mkdb -p /etc/master.passwd
 23# ls -l /etc/{,s}pwd.db
-rw-r--r--  1 root wheel 40960 Feb 24 20:19 /etc/pwd.db
-rw-------  1 root wheel 40960 Feb 24 20:19 /etc/spwd.db
 25#

It's a ZFS system. The jails all seem to be behaving themselves. The UIDs of the accounts the mail's shown up as are all over. Polkitd once, then uid 4001 ("jsmith"), then uid 3009 ("dwitt"), then 169 (ACME client), etc...

It's really very baffling, especially that the weekly run shows up (again today) as Charlie Root.

Rebooted 9 days ago, can do it again.
 
Still looking for ideas on how to troubleshoot this. The last week's worth of UIDs: 4001, 1005, 3006, 4001 (again), 3012, 3008, 4001 (yet again). No obvious pattern that I've been able to discern, all but 1 of those are basically inactive accounts.

Is there any way a local script that does various per-user things (spam reporting) could somehow cause this? ...but as I think about it, that reporting script would run from daily only, not from security. Hmph.
 
Consdering:
if the periodic would actually run as the wrong user, then the report should probably contain some complaints as that user cannot access relevant things.
Otherwise, the issue would appear somewhere at the handover to the mailer. Sendmail would report the user in the log: ctladdr=<root@edge.intra.daemon.contact> (0/0) - but I have no idea if you guys do still use sendmail...

And BTW, cron and periodic are different things. The disposal of periodic logs is configured in /etc/periodic,conf, while the default cron output is configured, eh, elsewhere...
 
Sendmail ctladdr= log says the non-root user of the day. I think I'll add some debug noise to /usr/sbin/periodic to see what UID it's running under. It's run from /etc/crontab specifying root, and given how its output redirection works (a pipe to /usr/bin/mail that's set up before any of the scripts run) , I wouldn't expect what I'm seeing at all. So odd...
 
I seem to be sneaking up on it. I added a 10.id that just does id -p to both /etc/periodic/daily and /usr/local/etc/periodic/daily. Somewhere between those two, something apparently called setlogin(). Relevant bits:

Code: 
239# cat 10.id
#!/bin/sh
#
echo "Executing under ids"
id -p
240#

and then the excerpt bits from last night's daily run:

Code: 
Executing under ids
uid root
groups wheel operator

Removing stale files from /var/preserve:

[ ... ]

Checking userland and kernel versions:
Userland and kernel are in sync.

Executing under ids
login _tss
uid root
groups wheel operator

Backing up pkg database:
...

So I guess I start sprinkling id scripts in /etc/periodic/daily...
 
I have a strong suspicion it's 300.calendar, and the calendar -a functionality, but I'm still puzzled about how a child process is impacting the parent shell's login user ID.

(And just for the record? Debugging things in periodic/daily is ... fun. Experiments take 24 hours.)
 
...and I just proved that it's 300.calendar causing the problem. Now to figure out why. But I should probably just email freebsd-users...
 
SteveW said:
...and I just proved that it's 300.calendar causing the problem. Now to figure out why. But I should probably just email freebsd-users...
Click to expand...
It does appear that calendar(1) changed between 14 and 12.

The man page for 12.4 states for the "-a" option:
Process the ``calendar'' files of all users and mail the re-
sults to them. This requires super-user privileges.
Click to expand...

And the 14.1 version:
Process the ``calendar'' files for users found in /etc/passwd
and mail the results to them. This can result in multiple mes-
sages for specific files, since /etc/passwd does not require
home directories to be unique. In particular, by default root,
toor and daemon share the same home directory. If this direc-
tory contains calendar information, calendar will process the
file three times.
Click to expand...

I wonder if the home directory for _tss is also /root?
 
No, the home directory for _tss is /var/empty. And I've seen plenty of regular users with /home/{whatever} in the output as well.

The excitement continues, though:

Code: 
(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#

...and now that xterm is stuck with the logname as the regular user jpick3543. Tried su -, su -m, su -l, no difference in id -p output.
 
You must log in or register to reply here.
Back
Top