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)
-
How are you running this script? From crontab?Chris Davies– Chris Davies2019年11月24日 13:37:42 +00:00Commented Nov 24, 2019 at 13:37
-
yes the script is launched by crontab (I've updated question to specify this)Jean Monet– Jean Monet2019年11月24日 13:48:52 +00:00Commented Nov 24, 2019 at 13:48
1 Answer 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.
-
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 thesudo
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 issudo
ing, and would not want to mirror the Python installation package forroot
user.Jean Monet– Jean Monet2019年11月24日 14:48:40 +00:00Commented Nov 24, 2019 at 14:48 -
Could it be a system-wide installation of Python?Chris Davies– Chris Davies2019年11月24日 15:14:13 +00:00Commented Nov 24, 2019 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 forroot
), so the binary is located in/home/[USER_NAME]/anaconda3/envs/[ENV_NAME]/bin/python
. I didsudo su
and ran the Python script (./python_script.py
) asroot
. 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 asroot
. Is this behavior normal / expected?Jean Monet– Jean Monet2019年11月24日 15:48:54 +00:00Commented Nov 24, 2019 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– Chris Davies2019年11月24日 15:51:49 +00:00Commented Nov 24, 2019 at 15:51
-
1Ohh 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– Jean Monet2019年11月24日 16:12:27 +00:00Commented Nov 24, 2019 at 16:12