This is the mail archive of the cygwin@cygwin.com mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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/


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]