Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!wuarchive!uunet!mcsun!hp4nl!utrcu1!mi.eltn.utwente.nl!klamer From: klamer@mi.eltn.utwente.nl (Klamer Schutte) Newsgroups: comp.os.minix Subject: Re: #! in MM -- take 2 Message-ID: Date: 24 May 91 06:54:56 GMT References: <10033@star.cs.vu.nl> Sender: news@utrcu1.UUCP Organization: University of Twente, BSC-El Lines: 96 In <10033@star.cs.vu.nl> kjb@cs.vu.nl (Kees J. Bot) writes: >I'm posting my comments to Klamer's second try at an #! implementation in >MM to remind you about my implementation of #! that I posted on May 13. >klamer@mi.eltn.utwente.nl (Klamer Schutte) writes: |>Here is the second version of my #!interpreter patch for mm/exec.c. |>This version has all known bugs fixed. >Except for not doing setuid and this other "feature". I said i had bugs fixed. Setuid in your way is a bug. |>One feature (bug ???) remains: i keep alignment from the data argv[] and |>envp[] point to intact. There (migh ???) be a tradition of having this |>data in the form of strings with only 1 \0 in between. |>Where is the manual page for execve(2) ???? Or does POSIX(*) say anything |>about this? >I know of three places to look for the proper format of the initial stack: >- The old V7 manuals under exec(2), written when users were not considered > too stupid to know such things. >- The source code of execve(2). >- The source code of ps(1). >The ps(1) source contains this interesting comment: 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. >I decided to go over Klamer's patch with a fine comb this time. (I wish >someone would do that with my patch, with a mental -pedantic flag on.) Good initiative. Any Minix'er is invited to do so. >- ALIGN align to a multiple of 2, execve to a multiple of sizeof(char *). Yep. The comment near ALIGN says this is the correct alingment for an Atari ST. You know, that 16 bits machine ... >- The interpreter is found relative to '/'. (Move the first > tell_fs(CHDIR, ...) inside the do loop.) This is a bug, yes. Not to bad -- the interpreter should be specified with an absolute path in traditional (;-) #! implemetations. (Like SunOs). >- Setuid bits on the script are still ignored. (Wouldn't it be nice to > allow people to explore the security risks of a setuid script?) They can. They only have to change mm/exec.c. Any user not capable of doing that should not explore security risks ;-) >- Change 'know' to 'now' in patch_stack. (-pedantic) >- The old argv[0][] is not removed from the initial stack. See the earlier comments about the stack format. >- 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[]. >- 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 ...) >- Read_header returns 0 when there is nothing behind #!. Bug. >- The size_ok function may return something other than -100. Can't check now. Don't have full minix online. 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. Can anybody with a POSIX copy at hand clearify what the correct stack format is? My old V7 manual (for a m68k system) only says something about pdp11 and interdata stack layouts... Klamer -- Klamer Schutte Faculty of electrical engineering -- University of Twente, The Netherlands klamer@mi.eltn.utwente.nl {backbone}!mcsun!mi.eltn.utwente.nl!klamer