Ansible and sudoing to a user other than root … making it smoother?

Archives Ansible Project
1

I wanted to validate my logic on something.

If you are sudoing to a user other than root, you have to transfer a module file. For legacy modules it's a module file + an arguments file, but that's simply not true if you are using one of the newer style modules -- just one file to transfer. Easy enough.

When this happens, the initial module file transfer has to happen as YOU, before you sudo.

In this event the file is written into the original user's homedir, as while I can chmod, only root is allowed to chown.

An obvious solution that comes up, which I have rejected, is if sudoing to non-root to write the module file into /tmp, but this is horrible, because there is a brief (sub second) window when it would be manipulable before it is executed. Some sort of way to sign off on this could be added, I guess, but it seems that in doing so we make an unwise decision.

The solution here, as it has been, is to set ANSIBLE_REMOTE_TMP to a directory that both the originating user and the sudo_user, which can be /tmp if you so desire and have chosen to do so. However this variable is used all the time. Perhaps what we really want is something like ANSIBLE_SUDO_NONROOT_TMP? But that seems obscure…

Either way, if you do it wrong, you get a permission denied error, and that usually results in someone wanting to ask a question. As you may know, I like to code around questions so they are self explanatory and don't get asked a lot.

Now, what I could do is look if ANISBLE_REMOTE_TMP is not set by the user, and try to use "/tmp", and print out a big scary warning. I could do that. But I haven't, because I thought this was generally risky.

Thoughts on how to make this smoother? Do we just allow ANSIBLE_SUDO_TO_NON_ROOT_UNSAFELY or something, off by default?

(By the way, we're going to have a config file soon… it will be totally optional. I recognize that we now have too many environment variable thingies, I'll still respect those, but I also don't want to add everything to the CLI either…so… yeah, it will be easy to see what things are easily tweakable without inside knowledge soon enough)

If this is confusing and you've never tried to do this, please ignore me… I know it's probably a reasonably small minority that isn't logging in as them and moving to root, or just being them, or just being root. Sudoing from "bob" to "timmy" is a corner case, but I would like to make it smoother if possible.

--Michael

2

I'm not sure I fully understand the manipulation vector? File gets uploaded to /tmp, only writable by the original user (bob in your example). timmy might not even be able to read it, but he certainly won't be able to write to it, or delete it, will he? So the process is upload the file as bob, *loosen* the security so that timmy can read it, and then timmy can execute it.

I'm certainly interested in this approach, although I may well investigate how suitable logging in and then su'ing to a non-root service account is through the ssh libraries too.

Will

Actually you're right here, I'm over thinking things.

The file is transferred and is (usually) going to be world readable if put in /tmp, but it's only writeable by the user.

On another front, I'm considering changing the "chmod +x" in the internals to "chmod 700", most likely.

--Michael

3

Just to provide some context on this (since I was the one who initially ran into this issue), the motivating use case is configuring PostgreSQL on Ubuntu.

On Ubuntu, the root user account is disabled over ssh by default, so you need to ssh as a non-root and sudo to do admin stuff. (On Ubuntu-based Amazon EC2 instances, this user is typically “ubuntu”. On vagrant boxes, this user is typically “vagrant”).

When you install postgresql on ubuntu, it creates a “postgres” user that has admin access to postgresql without the need for a password.

So, to set up postgresql on Ubuntu, you need to sudo to the postgres user.

Take care,

Lorin

4

The systems I use typically have a umask of 027 so would need to have world readable permission granted.

chmod 700 wouldn’t work as well as 755 for this use case - perhaps you meant the latter.

Will

5

I'm see about intelligently deciding how we chmod to based on desired users.