0

I've set up a bash script to run automatically (from crontab) with sudo privileges using this visudo solution.

Since the script requires multiple runs, it pollutes my /var/log/auth.log, so I disabled the TTY output (only for the specific script I designated in visudo) by following this solution successfully. By TTY, I mean this kind of log entry: [user] : TTY=unknown ; PWD=... ; USER=root ; COMMAND=....

But I'm left with the following 2 lines in /var/log/auth.log each time the script is run (it being run with sudo privileges). Since it runs many times, I have this output many many times, which is annoying:

Nov 01 00:00:00 1234567 sudo: pam_unix(sudo:session): session opened for user root by (uid=0)
Nov 01 00:00:00 1234567 sudo: pam_unix(sudo:session): session closed for user root

I'm aware of this question: How to stop sudo PAM messages in auth.log for a specific user?, which seems to allow the disabling of PAM messages per user.

But I couldn't find a solution to disable the above PAM message in /var/log/auth.log for a specific script only. Basically I'm looking for the equivalent of what I did for the TTY output with visudo, which carves-out from logging only the specific script I've designated.

Any ideas?

(The system is running Ubuntu 18.04 LTS)

Jean Monet
  • 265
  • 2
  • 5

1 Answers1

1

If the script is being run from crontab one option would be to run it from root's crontab (or the system one) so that sudo is no longer required.

Chris Davies
  • 116,213
  • 16
  • 160
  • 287
  • The reason I didn't include it in root's crontab is that the script is actually a Python script itself running some bash scripts (the bash scripts being the ones that require the sudo privilege and that leave traces in logs). The requirement is that I use the Python installation (with related binary and installed packages) that is available for the user that is sudoing, and would not want to mirror the Python installation package for root user. – Jean Monet Nov 24 '19 at 14:48
  • Could it be a system-wide installation of Python? – Chris Davies Nov 24 '19 at 15:14
  • I just tested and it works, thank you. Python is installed in an environment with the Anaconda distribution (itself installed for user, not for root), so the binary is located in /home/[USER_NAME]/anaconda3/envs/[ENV_NAME]/bin/python. I did sudo su and ran the Python script (./python_script.py) as root. The script has a header pointing to the Python binary #!/usr/bin/env /home/[USER_NAME]/anaconda3/envs/[ENV_NAME]/bin/python. This seems to work correctly, the Python packages remain available even if script is run as root. Is this behavior normal / expected? – Jean Monet Nov 24 '19 at 15:48
  • If you run programs underneath an ordinary user's account as root, you've just thrown all your root security away. (The non-privileged user can change or replace the application you're running as root to get root access.) If you're doing that you really would be better off installing whatever tools it is as part of a system-wide installation. – Chris Davies Nov 24 '19 at 15:51
  • 1
    Ohh thank you for pointing that out. Going on this path, I've found a guide to install Anaconda system-wide, which seems to account for the point you raised (Remove write permission for ‘group’ and ‘others’). I'll consider this path as it would require me to re-install the Anaconda package and environments, and use a common environment. In the meantime if a solution for PAM messages is feasible, I'd be grateful. – Jean Monet Nov 24 '19 at 16:12