This is the mail archive of the
cygwin@cygwin.com
mailing list for the Cygwin project.
RE: ksh on cygwin
- From: "Karsten Fleischer" <K dot Fleischer at omnium dot de>
- To: <cygwin at cygwin dot com>
- Date: Fri, 11 Jan 2002 02:04:47 +0100
- Subject: RE: ksh on cygwin
> >>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.
It's not a major change.
SUSv2 doesn't say that you have to use /bin/sh for a shell. It even says
that $SHELL can name the user's favorite shell.
I know that you always have trouble with users who copy /bin/bash to
/bin/sh, it's a monthly issue on the mailing list. My patch would solve this
in an easy way.
Regarding the security issues, as Corinna pointed out there's no "superuser"
with uid == 0, so the things I proposed above can be dropped.
Karsten
--
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/