Using sudo in openSUSE without actually changing to root user (i.e., like in Ubuntu)

Question

I recently started trying openSUSE 12.3 after having used Ubuntu for a few years. I'm still getting used to openSUSE's treatment of su (and sudo) vs. Ubuntu's use of sudo. I've been reading the openSUSE manual, but can't figure out answers to two related questions:

1) In a previous question at https://askubuntu.com/questions/236859/are-there-adverse-effects-from-or-a-better-way-than-writing-to-run-or-dev-sh, I asked about writing a decrypted gpg file temporarily to /run using the gpg --output flag so that the decrypted file would never touch the hard disk. In order to write to /run, however, I needed to use sudo in Ubuntu (i.e., sudo gpg --output '/run/temporary_file_name' etc.).

When I try to do the same thing in openSUSE (using either sudo or su), I get an error message from gpg, presumably because the root user cannot see my user account's gpg keys. Can this use of ``sudofrom Ubuntu, in whichsudoseems to use the same preferences / gpg keys as the regular user, be replicated in openSUSE? I could usegpg etc. | tee etc.`, I suppose, but that seems unwieldy compared to Ubuntu's way of doing things.

2) I have several bash scripts from Ubuntu that require root privileges for some, but not all, lines (e.g., copying files that I don't want to get owned by root, but then installing new software, which requires root privileges). In Ubuntu, I could just have some lines start with sudo. sudo some_command doesn't always seem to work in openSUSE, though. Is the best way to adapt these scripts for openSUSE to use su -c 'command' on those lines of the script? If I use su by itself in the script, the script stops working after I enter the root password.

Please note that, while I'm asking about openSUSE specifically, this question presumably applied to many non-Ubuntu distros.

Answer 1

Whether sudo preserves the HOME environment variable or sets it to the target user's home directory depends on its configuration (see the manual for details). It's not Ubuntu doing it right and SuSE doing it wrong, or vice versa: there are upsides and downsides to both choices. It's your job as a script writer to cope with both cases. The solution to (1) is to either run sudo -H or pass --homedir to gpg.

However, running gpg as root is definitely the wrong approach. This gives gpg too many privileges, and may the privilege to access ~/.gnupg away from it (e.g. if the user's home directory is on NFS). Run gpg as the user who owns the key, and make it print the data to standard output. Piping into tee is the standard way to output to a file that you need special privileges to write (I have no idea why you consider it “unwieldy”):

gpg -d foo.gpg | sudo tee /run/foo

Whether su or sudo is needed to become root depends on the system administrator's choice. Different users on the same machine may use one or the other. Unless you control the configuration on all machines you'll run your script on, allow for both possibilities (e.g. with an option passed to your script).

If your scripts work on Ubuntu with sudo but fail on other distributions or with su, you may be relying on the environment being (almost) completely reset. That's the default sudo configuration on Ubuntu but other systems may behave differently. Fix your script so that it doesn't depend on the environment being reset.

Answer 2

This is primarily an answer to question 1 since the other is a separate question that I don't have time to address right now.

Ubuntu takes some shortcuts on security to appeal to typical desktop users who don't want or need the added complexity of full privilege separation. However, if you are handling data that is so sensitive that you don't want to write it to disk, then you are not such a user and should not bypass the standard security architecture by implementing Ubuntu-style sudo rules.

WARNING: Just because you put something in RAM doesn't mean no one else can get to it. The most obvious culprit is on-disk swap, which can end up storing the contents of what was on the RAM indefinitely. But other compromises are possible as well.

So if you've disabled your swap partition and consider that good-enough:

A better option than writing to /run is probably creating your own tmpfs mount owned by the user whose going to use it. For example, if your user and group IDs are both 500:

mount -t tmpfs tmpfs /home/jl/realtmp -ouid=500,gid=500

This command will have to be run as root, but once you have perfected this setup, you can add it to your fstab to make it permanent:

tmpfs   /home/jl/realtmp    tmpfs   uid=500,gid=500 0   0

Answer 3

I would enable sudo. This is done by editing /etc/sudoers file and adding the line user ALL=(ALL) ALL. With the desired user. This has to be done as root.