Transfer files using sudo

[Fedon Kadifeli]

We are trying to eliminate the use of passwords for *generic* users like root, oracle etc. To do this we plan to use sudo and give permission to *specific* users to switch to root, oracle etc. using "sudo -i" for example.

This solves the problem of logging in as a generic user to the system. However, from time to time there will be a need to transfer files (using scp, sftp or whatever) to or from a system using a *generic* user. For example assume you want to transfer a very large file to your PC which can only be accessed by the root user.

How do you satisfy that kind of needs in real life?

[Steven Schweda]

> How do you satisfy that kind of needs in
> real life?

Fix the contradiction in the requirements?
Correct me if I'm wrong, but you seem to want
a non-root user to be able to access a file
"which can only be accessed by the root
user."

[Fedon Kadifeli]

Yes.

Let me be more clear.

User "user1" is a system admin and can use "sudo -i" to get root shell (so he/she can do anything a root can do without knowing the actual root password). How can "user1" transfer a file which can only be accessed by root? The option of chmod/chown or cp the file to give it "user1" ownership is not acceptable, considering it is a very large file that needs to be kept secure.

[David Child_1]

Your best bet is to set up ssh keys, then you can transfer files as root (or oracle, etc.).

Note: In this example I'll use oracle (note: this is very high level);
1) create key on source system (ssh-keygen) as oracle (this will be in ~oracle/.ssh)
2) copy public key to destination system and put in oracle's ~oracle/.ssh/authorized_keys file.

Now you can scp files from source->destination as oracle without needing the password.

Note: when creating the key it will give the option of creating a pass phrase. I would recommend doing this. If you need to automate your process you can use an ssh key agent to help with the pass phrase.

David

[Fedon Kadifeli]

"ssh keys" was an option that we are considering. Any other more flexible options from "real life"?

[Steven Schweda]

SSH is pretty flexible (and real).

> [...] considering it is a very large file
> that needs to be kept secure.

It's easier to consider requirements like
this when they're known. Perhaps you should
make a list. SSH access as "root" may allow
a non-root user to do more than copy files,
too.

[Steven Schweda]

> Let me be more clear.

> [...] How can "user1" transfer a file which
> can only be accessed by root?

That's clear. It's impossible. Either
"user1" _can_ access the file, or else only
"root" can can access the file. They can't
both be true. There are various methods by
which "user1" might access a well-protected
file, but there's no way to access a file
which can't be accessed.

If you wish to give "user1" read access to a
file, this could be done using an access
control list. "man 5 acl".

[Fedon Kadifeli]

Let me be more specific about my needs. I (as a system admin) want to give the *specific* user "johnthedba" full "oracle" user priviledges without giving the password of "oracle". Actually nobody in the universe (including me) will know the password of "oracle" user.

The user "johnthedba" will do anything "oracle" can do including copying files in and out of the system. The "ssh keys" (mentioned above) is an option; however it is very slow while copying file over a Gbps LAN environment. The user "johnthedba" will copy large oracle export files to or from other systems. These files are owned by "oracle" and nobody else will have read or write access to these files, including the directory they are stored. Currently we are using ftp because it is much faster than scp or sftp.

I am considering using an ssh and netcat (nc) combination. Any other ideas?

[Tingli]

You can either sudo the user as oracle, or set all the oracle files as 770 with this user having the same group as oracle.

As for file transfer, you can use a specific command line in sudo as oracle for this user.

[Heironimus]

Something like this can work with appropriate sudo configuration and a decent ssh client:

ssh youruser@yourserver "sudo cat /something/secure" >local_copy

As for keys... they're a good solution in some situations, but letting users have ssh keys for generic accounts is almost the same as giving out the password. In both cases there is "something" that will give anybody who has it the ability to act as that user. Correctly controlling access while using ssh keys in this manner will probably be difficult.

[Mel Burslan]

This method is a little more complicated, but since your user can sudo into root (or oracle or any other application service account for that matter), he/she first can login to the interactive shell via ssh (or god forbid telnet) and modify the file permissions temporarily to allow his/her own user id to be able to read these files to be copied to the local workstation, then using the favorite scp client, files can be pulled to the workstation and upon completion of copy coperation, the file permission could be reset to what they were, prior to this activity.

I know it is not convenient, but the price of security is inconvenience. You have to pay the piper at one point. So, pick your poison... :)

[Steven Schweda]

> [...] I (as a system admin) want to give
> the *specific* user "johnthedba" full
> "oracle" user priviledges without giving
> the password of "oracle". [...]

If a user has 'full "oracle" user
privile[d]ges', why not give him the "oracle"
account password, too? How much more damage
could he cause that way?

Methods like ACLs and "sudo" are used to give
and _restrict_ special privileges. If you
really want to give away the whole store, why
not hand over the keys and the deed?

On the other hand, if you want to allow some
user(s) to be able to perform certain limited
tasks which require special privileges, then
selecting the best approach might require
defining exectly what those tasks are.

[Fedon Kadifeli]

The problem is that administration wants to get rid of *generic* users (root, oracle, etc.). Let's say we have two DBAs: John and Mary. These two people should NOT share the password for "oracle"; but instead have their own users (say "johnthedba" and "marythedba"). They will login to the system using their own *specific* users. When they need to do their DBA duties for the Oracle databases on the system, they will switch to "oracle" user using "sudo -i".

[Frank Ng]

Since user1 have admin access to these files via sudo, then all you need is ...

oracle:

sudo -u oracle scp user1@remotesystem:/path/file .

When the file lands on the localhost, it will land as being owned by oracle.

root:

sudo scp user1@remotesystem:/path/file .

When the file lands, it will be owned by root.

Assumptions made here is that for the oracle example, that user1 has read access to these files you are trying to copy. In our environment, all files are owned by oracle:dba and our dba admins are all in the dba group with at least 640 permissions.

It is very possible for files that can only be accessed by root to be access by normal users with sudo (given that the normal user is given full sudo access). Without running sudo, the same user1 will not have access to that file.


Hope this helps.

-fng