tags:

views:

154

answers:

5

I need to programmely switch the current user to another,then the followed code should be executed in the environment(such as path,authority..) of another user. I've find the 'chroot()','setuid()' may be associated with my case, but these functions need the root authority, I don't have root authority, but I have the password of the second user. what should I do?

I have tried shell "su - " can switch current user, can this command help me in my C++ code?

Don't laugh at me if my question is very stupid, I'm a true freshman on linux. :) Thanks!

A: 

You can use the system function to execute shell commands on the operating system.

DeadMG
Thanksvery much! I will try it.
jnblue
A: 

You could take a look at the source code of the login command, or you could try using the exec()-family functions to call on login.

EDIT: Seems like you will need root access in any case.

Maister
Thanks! I think I should call exec("su - USERA...."),but I also want to know, when the exec return, if the environment of the thread will switch to the user's who called 'exec()',or keeps the USERA's..
jnblue
When you call exec() the calling process image will be completely replaced with whatever you have executed. If you want to go this way you will need to fork a copy of you process which will then call exec().
Frank Meerkötter
A: 

Is setuid what you're looking for?

Iulian Şerbănoiu
No, setuid need the root access.
jnblue
Follow the link. The setuid file flag switches the current user to the owner of the file. It is a security risk but might in your case be the correct solution. Implement your program to work via stdin/stdout, store it with setuid set for the correct user and then access the program (i.e. via system() or exec()) from whereever you need the information.
dbemerlin
A: 

when clients connect to the server, the server transfer the data what they need,but the precondition is the correct username and password.

If your primary requirement is to authenticate, then try man pam. There are also some libraries allowing to auth over LDAP. Unfortunately I have no personal experience implementing neither.

Otherwise, recreating complete user environment is unreliable and error prone. Imaging a typo or endless loop but in user's ~/.profile.

I haven't done that for some time, but I would also have tried to dig in direction of "su", figuring out user shell (from /etc/passwd) and trying to exec() it as if it was a login shell (with "-"). But after that you would need somehow to communicate a command for execution to it and that's a problem: shells run differently in batch more and in interactive mode. As a possible hack, expect (man expect) comes to mind, but it is still IMO too unreliable.

I have in past used ssh under expect (to input the password), but it was breaking on customized user profiles every other time. With expect, to send a command, one has to recognize somehow that shell has finished initialization (execution of profile and rc files). But since many people customize the shell prompt and their profile/rc files print extra info, it was quite often that expect was recognizing shell prompt too soon.

BTW, depending on number of users, one can try a setup where users manually start the server under their own account. The server would have access only to the information which is only accessible to the user.

Dummy00001
Very useful infomation,thanks very much.If I find a good solution, I will let you know..
jnblue
A: 

I think the key point here is that you can't change the user of the running process (easily). All the programs like 'su' are effectively starting a new process as the specified user.

Therefore, in your design I would recommend seperating off the functionality that needs to be done into a different executable and then investigate using execve() to start it.

Richard M-S