john@tcom.stc.co.uk (John Blair) (09/02/88)
Below is the program I use to run a unix command under the userid of the
program owner.
However when the command passed is Make with parameters and
stdout and stderr file redirection I sometimes get segmentation
problems and core dumped.
If I "su" as the userid of the program owner
and execute the same Make command I do not get segmentation problems.
What is wrong with the C program?
/* note, this must run with set uid on execution */
main(argc,argv)
int argc;
char * argv[];
{
setuid(geteuid());
setgid(getegid());
execvp(argv[1],argv+1);
}leo@philmds.UUCP (Leo de Wit) (09/07/88)
In article <641@jura.tcom.stc.co.uk> john@tcom.stc.co.uk (John Blair) writes: | |Below is the program I use to run a unix command under the userid of the |program owner. |However when the command passed is Make with parameters and |stdout and stderr file redirection I sometimes get segmentation |problems and core dumped. | |If I "su" as the userid of the program owner |and execute the same Make command I do not get segmentation problems. |What is wrong with the C program? | |/* note, this must run with set uid on execution */ |main(argc,argv) | int argc; | char * argv[]; |{ | setuid(geteuid()); | setgid(getegid()); | execvp(argv[1],argv+1); |} Two things: 1) the arg count should be checked to be >= 2 (I don't think execvp likes a null parameter). 2) when you start the program the input/output redirection is done, perhaps by your shell. This means that these input/output streams must be readable/writable by the current uid/gid; when you setuid & setgid the process may not be allowed anymore to write these descriptors. Suggestion: either explicitly allow access to the stdout/stderr (e.g. create a file, chmod to correct permissions and do redirection by appending) or do a fchmod(fileno(stdin),mode) in the program; this you will have to do probably in a forked child which has reset the euid/egid to the original value, as only a file owner can change the mode (fork the child before the setuid/setgid, otherwise you cannot it change it back anymore). Hope this helps - Leo.
gwyn@smoke.ARPA (Doug Gwyn ) (09/08/88)
In article <794@philmds.UUCP> leo@philmds.UUCP (Leo de Wit) writes:
-|Below is the program I use to run a unix command ...
- 2) when you start the program the input/output redirection is
-done, perhaps by your shell. This means that these input/output streams
-must be readable/writable by the current uid/gid; when you setuid &
-setgid the process may not be allowed anymore to write these
-descriptors.
On UNIX, the permissions are checked when the files are opened,
not on each read and write. If the files got opened okay then
they should remain usable after the set*id() calls.tanner@cdis-1.uucp (Dr. T. Andrews) (09/09/88)
In article <794@philmds.UUCP>, leo@philmds.UUCP (Leo de Wit) writes:
) ...when you start the program the input/output redirection is
) done, perhaps by your shell. This means that these input/output
) streams must be readable/writable by the current uid/gid; when you
) setuid & > setgid the process may not be allowed...
Nope. Not the case at all. Once the file is open, the file
descriptor remains open, and usable, until such time is it is
closed (explicitly, via close(2), or implicitly via exit(2) or
exec(2) after ioctl(,,FIOCLEX)).
--
...!bikini.cis.ufl.edu!ki4pv!cdis-1!tanner ...!bpa!cdin-1!cdis-1!tanner
or... {allegra killer gatech!uflorida decvax!ucf-cs}!ki4pv!cdis-1!tannermaart@cs.vu.nl (Maarten Litmaath) (09/10/88)
In article <794@philmds.UUCP> leo@philmds.UUCP (Leo de Wit) writes:
\ 2) when you start the program the input/output redirection is
\done, perhaps by your shell. This means that these input/output streams
\must be readable/writable by the current uid/gid; when you setuid &
\setgid the process may not be allowed anymore to write these
\descriptors.
That is simply not true: if you have an open file descriptor, you can write
to it (presuming it has been opened for writing).
Concerning the original problem: maybe an example will shed some light upon
the matter?
--
Alles klar, |Maarten Litmaath @ Free U Amsterdam:
Herr Kommissar? |maart@cs.vu.nl, mcvax!botter!maartbill@proxftl.UUCP (T. William Wells) (09/13/88)
In article <794@philmds.UUCP> leo@philmds.UUCP (Leo de Wit) writes: : In article <641@jura.tcom.stc.co.uk> john@tcom.stc.co.uk (John Blair) writes: : | : |Below is the program I use to run a unix command under the userid of the : |program owner. : |However when the command passed is Make with parameters and : |stdout and stderr file redirection I sometimes get segmentation : |problems and core dumped. : | : |If I "su" as the userid of the program owner : |and execute the same Make command I do not get segmentation problems. : |What is wrong with the C program? : | : |/* note, this must run with set uid on execution */ : |main(argc,argv) : | int argc; : | char * argv[]; : |{ : | setuid(geteuid()); : | setgid(getegid()); : | execvp(argv[1],argv+1); : |} : 2) when you start the program the input/output redirection is : done, perhaps by your shell. This means that these input/output streams : must be readable/writable by the current uid/gid; I don't think this is correct. When a file is opened, you are given certain access permissions. These permissions do not change, even if your uid/gid changes. --- Bill novavax!proxftl!bill