Mastodawn

Trying to make Cron/PAM shut up and not be so noisy in my logs and… I'm not liking the solutions. Or at least, I'm not liking how I have to apply the solutions.

One site (https://languor.us/cron-pam-unix-cron-session-session-opened-closed-user-root-uid0) tells you to make edits to /etc/pam.d/common-session-noninteractive and doesn't explain what `pam_succeed_if.so service in cron quiet use_uid` does (I can guess, but still… that's a central file)

And Ask Ubuntu post (https://askubuntu.com/a/465632) suggests editing /etc/pam.d/cron for a different problem and it's workable but still not great.

I want something that Just Works™ from Infrastructure-as-Code (Puppet). I don't like editing the middle of files that might change.

Cron: pam_unix (cron:session): session opened/closed for user root by (uid=0) | languor.us

This is my week of playing around with mail servers and I have been keeping an eye on the logs on a regular basis. I noticed that the auth.log was riddled with millions of these pointless (from my POV anyhow) log entries: CRON: pam_unix(cron:session): session opened for user root by (uid=0) CRON: pam_unix(cron:session): session closed for user root

There is a Puppet module for handling PAM (multiple, actually - but one by a user that I've seen frequently before). But… that seems like overkill just to edit one file to reduce some logging!

Ahhhh, there's a Vox Pupuli (which seems to be semi-official add-ons) that uses Augeas. Maybe that's powerful enough and the files are structured enough for it to work 🤔

"Error sending command 'insert' with params […]"

Awesome, Puppet. Very helpful. Any clues on WHAT the error was and why the command didn't send successfully? 😐

Kinda getting there. Added `--debug` to Puppet and grepping for Augeas in the output.

I _think_ the commands are right (an `insert before` followed by multiple `set` commands) but I'm currently getting `Unexpected node … can not match tree` and I don't know why.

#Puppet #Augeas #PAM #SysAdminProblems

Now managing to see where in the Augeas lens it's failing and… it's still not clear.

It doesn't like the "record_svc" line, apparently. But if I do a `print` then it _looks_ the same as the existing lines to a human eye 😕

https://github.com/hercules-team/augeas/blob/master/lenses/pam.aug#L63

augeas/lenses/pam.aug at master · hercules-team/augeas

A configuration editing tool and API. Contribute to hercules-team/augeas development by creating an account on GitHub.

GitHub

I hate tools that seem to have some kind of internal representation and they can parse existing data but they can't show you how your new data doesn't match 😐

AHAH! It's the arguments. They've got to either be a string without spaces OR in square brackets. Which isn't what this fix needs, apparently. It needs multiple words without any sign of square brackets. So… let's see how this goes 😬

Chris Siebenmann 4d ago

@ibboard Programmatic PAM modifications are basically hell because every Linux distribution does things differently and the differences can be subtle and surprisingly impactful. No one has a good solution for the PAM mess.

(This may be one reason Polkit took off, you can at least drop separate rule files into it and etc.)

@cks Augeas is working for now. Nearly. But probably mostly because I'm only targeting Ubuntu (so I can "insert before" an include to get in the right place).

It's annoying that this is even a PAM thing. All I want is for it to not say "opening session for cron" and "closing session for cron" every single time a cron job runs. Because the server has several cron jobs that run every few minutes!

@cks Luckily I'm just messing with Cron, so the risk of screwing EVERYTHING up and locking myself out of a system should be zero. I'm just editing the cron-specific config and the non-interactive session one. Not touching anything user-related!

Chris Siebenmann 4d ago

@ibboard Based on the documentation and code, I think you can do this by just changing the 'session pam_unix.so' pam line to have 'quiet', assuming you're willing to take out all noninteractive 'opening session for' notices. But pam_unix doesn't currently do anything for session open and close other than log those, from what I can see.

(Why log at all? I dunno. Clearly they're aware not everyone wants them, since they put in 'quiet' explicitly for this.)

@cks That seems like a better option. I'm currently trying to add a "pam_succeed_if.so" line and while I _think_ it's safe (and it does seem to stop the logging) then I wasn't 100% sure.

PAM does not have the most helpful (or discoverable) documentation in terms of "here's a crash course on how things interact and what a new line might do".

Chris Siebenmann 3d ago

@ibboard I have just done horrible things with pam_succeed_if and I have feelings about that. My kingdom for some actual logic, instead of a sequence of conditional GOTOs with weird syntax.

@cks It's only an auth system. What's the worst that could happen? 😬

@cks Hmmmm, modifying the `pam_unix.so` line in `common-session-noninteractive` is _probably_ okay. I guess it would stop it logging _all_ non-interactive session creation rather than just Cron. But there doesn't appear to be any other non-interactive sessions on my server. Only seeing cron:session, runuser:session and sudo:auth/sudo:session logged under pam_unix.

Which isn't a perfect answer. Because you'd ideally want to know about all unexpected non-interactive sessions in case someone was exploiting it. But then I guess even silencing Cron is hiding some of those sessions. But can you REALLY tell the difference between "Cron woke up and ran the 'every minute' job" and "Someone made Cron execute something that it shouldn't"? 😁