This is the mail archive of the
cygwin@cygwin.com
mailing list for the Cygwin project.
Re: ksh on cygwin
On Thu, Jan 10, 2002 at 03:37:41PM +0100, Corinna Vinschen wrote:
>On Thu, Jan 10, 2002 at 09:13:01AM -0500, Fleischer, Karsten (K.) wrote:
>>Glenn found some test cases where mmap() failed and has also written a
>>nice test program. I will get this to you later. He also states that
>>the value returned by getpagesize() must conform to mmap() alignment by
>>definition in the SUSv2. I'm not quite sure about that, though.
>
>See my reply to Robert. It's just an example. I don't have another
>reason at hand now but we already considered that change and we
>actually *had* reasons to avoid it. Perhaps Chris can help out here.
Sorry, I don't remember the discussion.
>>>We have some vfork() changes in the meantime and even ash had an
>>>related error which should be fixed.
>>
>>Maybe we fixed the same error. I'll send you the details.
>
>Please compare with the current CVS. Vfork() isn't in my expertise.
>
>>>>- use the contents of $SHELL instead of /bin/sh for
>>>execvp()/execlp() and system() (with some additional checks, e.g. do
>>>not use a csh, use only 'trusted' shells from /bin, /usr/bin,
>>>/usr/local/bin etc.). This allows the user to select his favorite
>>>shell manually, so no more "copy /bin/bash to /bin/sh" troubles. (This
>>>is also from UWIN).
>>>
>>>Hmm, interesting idea...
>>
>>OK, more detailed. I allow only absolute pathes in $SHELL and don't
>>allow any *csh. If superuser then only shells from [/usr][/local]/bin
>>are considered trusted shells. If not superuser shells from other
>>directories are allowed, but if uid != euid or gid != egid the shell
>>and the directory where it resides must not be writable. Fall back
>>value is /bin/sh.
>
>But, uhm, what exactly is a `superuser' from your point of view? We
>don't have that concept except for SYSTEM as _the_ user which is able
>to change user context w/o changing security policies. And on 9x/Me...
It sounds like all of this is pretty non-standard, AFAICT. I can see
why you'd do something like this but I don't think there is any reason
to divert cygwin in this direction at this point in its life. It's
a pretty major change.
cgf
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/