4

I have a script that moves in and out of using sudo. Certain commands have to be executed as $USER and certain commands have to be executed as root.

Currently, I'm running a loop in the background to keep sudo active so you execute the script, enter your password once, the script sudos the commands the it needs (runs the rest as regular user), and then the background loop terminates when the script does. This script is only run in a very controlled environment and I am not worried about the sudo access being left open during the process.

However, I'm also trying to log this script in a place that won't get cleaned up afterwards. Here are the pertinent parts of the script:

#!/bin/bash

logFile="path/to/log/file"

main () {
   # some getopts
}

getOptExample () {
   sudoFunction
   # do some other stuff that takes a really long time
   # and bounces back and forth between sudo and not sudo
   cleanUp
}

getOptOtherExample () {
   sudoFunction
   # do some other stuff that takes a really long time
   # and bounces back and forth between sudo and not sudo
   cleanUp
}

sudoFunction () {
    sudo -v
    while true;
    do
        sudo -n true
        sleep 60
        kill -0 "$$" || exit
    done 2>/dev/null &
}

cleanUp () {
    # remove script file
    # remove tmp dir that we're working in
    # reboot computer to apply all changes
}

(main "$@") 2>&1 | tee $logFile

I can't write to /var/log because the last line of the script happens before the sudo function is invoked, so it only has the permissions for the executing user. I also can't write to my tmp dir because it gets cluttered up and I need to remove the files in there after the script is complete. Also, the directory has no reason to stick around after the work that the script automates is complete.

  • I do have an account that has an unaffected home directory, but the user doesn't have permissions to create a file in that home directory.
  • This script is being run on mac OS, however, I'm trying to keep it as compatible with other/future/non-mac stuff (sticking to bash, trying to stick to posix, hell, even trying to stick with Linus' guidelines for adding to the Linux kernel).
  • I need the logfile to persist through at least one reboot

Where should I dump the logfile for this script that is:

  • Easy to find (intuitive)
  • User writable without sudo
  • Does not write to the user's home directory
  • Doesn't get deleted at reboot

Or is there a better way for me to do this (I can post the whole, huge script if necessary)?

3
  • Sorry about the odd question; managing our Mac devices is a task that I've been handed because "they're all Linux devices, right?" and I'm just trying to automate as much of this back out of my job as possible.
    – SSS
    Aug 30, 2018 at 3:55
  • Are you able to create files as root to store in /root/$SCRIPT_LOGFILE while you are bouncing in and out of user shells?
    – Tablemaker
    Aug 30, 2018 at 3:57
  • Technically yes, but the idea of the script is to elevate to root privileges once (with user interaction) and then continue without user interaction beyond that. I'm thinking that this is much more of a "I'm doing it wrong" than it is a "I can't do that". If /root/$SCRIPT_LOGFILE is user writeable without elevated privileges, then that is exactly what I'm looking for. edit: This is also mac OS, so /root doesn't exist as far as I know.
    – SSS
    Aug 30, 2018 at 4:08

1 Answer 1

2

Use basic file permissions or ACL to get that done.

There is e.g the group section in permissions, and a command called newgrp to switch the primary group. Also consider the SGID bit an using e.g. nobody as owner.

Not sure, if ACL is available on OSX, but I expect that it is there. Just use setfacl to allow the user|group to access and write to the logfile.

Typically /var/log/ should be used for logfiles. E.g. setup a folder in /var/log/yourscripname with proper permissions.

2
  • newgrp worked to allow me to set up the log file before authenticating.
    – SSS
    Aug 30, 2018 at 20:13
  • setfacl doesn't exist in mac OS (or BSD, I guess), but, chmod can be used to perform the same function; I was able to adjust the flow of my script and use newgrp (I'm not sure I really needed it once I started messing with everything again) to create the logfile in /var/log, change the group to staff, and give the group write permissions (using chown/chmod); it prevented the issue with certain things breaking in the way that my functions were set (error on my part) while allowing the authentication to happen before logging. The only thing that doesn't log is the original authentication.
    – SSS
    Aug 30, 2018 at 20:21

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .