Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!uunet!mcsun!hp4nl!star.cs.vu.nl!kjb From: kjb@cs.vu.nl (Kees J. Bot) Newsgroups: comp.os.minix Subject: Re: #! in MM -- take 2 Message-ID: <10055@star.cs.vu.nl> Date: 24 May 91 12:59:41 GMT References: <10033@star.cs.vu.nl> Sender: news@cs.vu.nl Lines: 63 klamer@mi.eltn.utwente.nl (Klamer Schutte) writes: >In <10033@star.cs.vu.nl> kjb@cs.vu.nl (Kees J. Bot) writes: >>klamer@mi.eltn.utwente.nl (Klamer Schutte) writes: >>Except for not doing setuid and this other "feature". >I said i had bugs fixed. Setuid in your way is a bug. It might be possible for an application to use a setuid script in a way that is not a security hole. Someone could place a a shell in /bin that is setuid root, but that is no reason to dissallow setuid for executables. If you want to protect users then add a wastebasket to /bin/rm. >How nice, to talk about self-documenting code. But i don't model system >call behaviour to assumptions made by any program. So ps(1), look at the >POSIX description of execve(). And yes, i have looked at the source code >of execve(2). This one is mm/exec.c right? The other one (lib/posix/execve.c) >is just an attempt to get the POSIX specification mapped to minix system. If the source of execve() is the best description you have for the initial stack then use it. Make sure that your modified stack looks like something execve() could have produced. There is no reason to make a mess of it just because there is no description in one of the many standards to choose from. BTW. there is no Berlin wall between execve() and mm/exec.c. Most UNIX systems pass the addresses of the argv and envp array up to the kernel and let the kernel collect the strings from user space. In Minix it is more convenient to build the initial stack in execve() and let MM fetch that. >>- The ALIGN(len) is still at the wrong place. Try moving only the strings >> by disp bytes, then move the pointers by argc*sizeof(char *) bytes. Do >> an ALIGN(disp) just before the return. >This will destroy alignment of the strings pointed by by argv[] and envp[]. Strings are made of bytes, and bytes have an alignment of 1, you can't destroy that! The argv and envp arrays are made of char *'s, so they need an alignment of sizeof(char *) in the worst case. >>- If stk_bytes is close to ARG_MAX then the last few environment variables >> may be truncated. >There are three choices overhere: >1) truncate some of the strings if stk_bytes is close to ARG_MAX >2) expand stk_bytes to bigger than ARG_MAX if ... >3) fail the execution if ... >I choose 1). You choose 3). 2) is IMHO out of the question. >Rethinking it, 3) might be the best choice. What is the proper error code? >ENOMEM specifies also that there is not enough core ... >(Don't tell me lib/posix/execve.c uses ...) Execve() uses E2BIG, mm/do_exec() uses ENOMEM for its first and normally useless check. I used ENOMEM in case 3) above, which I now see to be wrong thing to do. (Bug #1 in my version, finally.) >I must say this kind of bug finding is a good way to get rid of them. >But must this be on news? Private mail should be appropriate. You post it in public, so I comment on it in public. Why shouldn't other people know what's wrong with it? -- Kees J. Bot (kjb@cs.vu.nl) Systems Programmer, Vrije Universiteit Amsterdam