Home > Archive > Unix Programming > November 2005 > effective user id
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
|
|
|
| I have the code shown below. I have compiled it and changed the
ownership of a.out to user2:user2 and set the setuid bit (chmod 04755
a.out). Now I tried to run it as user1. The readdir system call
function works fine, the directory contents of /home/user2 get printed.
But, the 'system("ls -l /home/user2")', doesn't work, it gives the
error "ls: /home/user2: Permission denied". Any ideas how to make this
work? (btw, /home/user2 has the perms 700)
--------------------------------------------------------------------------
#include <sys/types.h>
#include <dirent.h>
int main(){
DIR *dirp = opendir("/home/user2");
struct dirent* dp;
while (dirp) {
int errno = 0;
if ((dp = readdir(dirp)) != 0) {
printf("%s\n",dp->d_name);
}
else{break;}
}
system("ls -l /home/user2");
| |
|
| Even an execve in place of system doesn't seem to work. Any
ideas/suggestions?
| |
| Casper H.S. Dik 2005-11-27, 7:00 pm |
| "raja" <vvrajarao@gmail.com> writes:
>Even an execve in place of system doesn't seem to work. Any
>ideas/suggestions?
What execve do you use?
Casper
--
Expressed in this posting are my opinions. They are in no way related
to opinions held by my employer, Sun Microsystems.
Statements on Sun products included here are not gospel and may
be fiction rather than truth.
| |
| Mr. Uh Clem 2005-11-27, 7:00 pm |
| Casper H.S. Dik wrote:
> In some cases the system() library call (which is really dangerous to
> use in set-uid programs) protects you against using it in a set-uid program
> by resetting the effective uid back to the real uid.
I've noticed some shells reset euid to uid, but not that system()s do
it as well. The burn about this resetting of euid to uid is that it
seemingly makes it impossible to have a program setuid a which
gets invoked by user b, and moves user data to uid a space then
become uid a so as to run backend scripting. Changing the uid
to a requires root privs, so that app must be setuid root.
That's hardly a way to increase security.
Have I missed something?
--
Clem
"If you push something hard enough, it will fall over."
- Fudd's first law of opposition
| |
| Casper H.S. Dik 2005-11-27, 7:00 pm |
| "Mr. Uh Clem" <uhclem@DutchElmSt.invalid> writes:
>Casper H.S. Dik wrote:
[color=darkred]
>I've noticed some shells reset euid to uid, but not that system()s do
>it as well. The burn about this resetting of euid to uid is that it
>seemingly makes it impossible to have a program setuid a which
>gets invoked by user b, and moves user data to uid a space then
>become uid a so as to run backend scripting. Changing the uid
>to a requires root privs, so that app must be setuid root.
Sorry for being imprecise; it's a function of the shell not
the system() call itself.
Changing the real uid does not require root privileges;
setreuid() allows you to set the real uid to the effective
uid:
setreuid(geteuid(), -1);
Casper
--
Expressed in this posting are my opinions. They are in no way related
to opinions held by my employer, Sun Microsystems.
Statements on Sun products included here are not gospel and may
be fiction rather than truth.
| |
| Mr. Uh Clem 2005-11-27, 7:00 pm |
| Casper H.S. Dik wrote:
> "Mr. Uh Clem" <uhclem@DutchElmSt.invalid> writes:
>
>
>
>
>
>
> Sorry for being imprecise; it's a function of the shell not
> the system() call itself.
Which it should be noted makes fork/exec a non-workaround.
> Changing the real uid does not require root privileges;
> setreuid() allows you to set the real uid to the effective
> uid:
>
> setreuid(geteuid(), -1);
>
Ahhh. I'd been limiting myself to setuid() (and seteuid().)
Can't find it now, but I thought I'd read an (HP?) man page
that said something to the effect that setresuid() might not
be supported in future releases, so I'd ignored it and 
setreuid() with it, ignoring setreuid() too. I trust
setreuid() is portable?? Obviously, I've got some research to
do tomorrow when I get in.
Hmm, a cautionary note from HPUX 11i setreuid man page:
It is unspecified whether a process without appropriate
privileges is permitted to change the real user ID to
match the current real, effective or saved user ID of
the process.
> Casper
THANKS, Casper!
--
Clem
"If you push something hard enough, it will fall over."
- Fudd's first law of opposition
|
|
|
|
|