SGI: Security

foetz wrote:

robespierre wrote:

Code: Select all

$ sudo -s
# chmod -x /bin/bash
# ln -f /bin/ksh /bin/sh

fuggeddaboutit....

i did the same on osx but with zsh. might work for linux, too

In fact, osx can't boot using ksh. But zsh does seem to work.
(None of the system scripts in osx use bash)

robespierre wrote:

foetz wrote:

robespierre wrote:

Code: Select all

$ sudo -s
# chmod -x /bin/bash
# ln -f /bin/ksh /bin/sh

fuggeddaboutit....

i did the same on osx but with zsh. might work for linux, too

In fact, osx can't boot using ksh. But zsh does seem to work.
(None of the system scripts in osx use bash)

Once upon a time OS X used zsh for the shell (IIRC). They switched to bash for Linux compatibility, because the Linux crowd believes they are the "One True Way."

With that said, I've updated bash on my IRIX systems manually (patched the source), we should consider making an update for nekoware....

armanox wrote: Once upon a time OS X used zsh for the shell (IIRC).

The default shell in OS X versions 10.0 through 10.2.x is tcsh. Apple switched to bash in 10.3.

armanox wrote: we should consider making an update for nekoware....

how about banning it?
who would use bash voluntarily on a real unix? even more so since zsh, tcsh and multiple ksh variants are available.

nobody needs bash. it's always been a mystery to me why it became so popular except for being the dummy shell for linux

foetz wrote:

armanox wrote: we should consider making an update for nekoware....

how about banning it?
who would use bash voluntarily on a real unix? even more so since zsh, tcsh and multiple ksh variants are available.

nobody needs bash. it's always been a mystery to me why it became so popular except for being the dummy shell for linux

Tempting on an emotional basis, perhaps. But because it is the only shell the Linux mob will ever think of, we will see complex scripts in packages that expect a current-ish version of bash. Better to have one with the proper security patches.

Also, folks coming from Linuxdom and picking up the SGI/IRIX habit will look around for bash pretty quickly. Might as well make it easier for them to indulge their new addiction, rather than creating an obstacle that prevents anybody from joining the club.

I saw the smiley, and I'm sure you can see these arguments for yourself. But what the heck, why not toss it in the thread for reference...

smj wrote: folks coming from Linuxdom and picking up the SGI/IRIX habit will look around for bash pretty quickly. Might as well make it easier for them to indulge their new addiction, rather than creating an obstacle that prevents anybody from joining the club.

hehe yes sure. although not having a specific shell might not keep them away completely. after all people who come from linux to unix/risc do that because they want something different i'd think.
there's not much sense in sticking to bash and gcc on every platform. makes it rather pointless

foetz wrote:

smj wrote: folks coming from Linuxdom and picking up the SGI/IRIX habit will look around for bash pretty quickly. Might as well make it easier for them to indulge their new addiction, rather than creating an obstacle that prevents anybody from joining the club.

hehe yes sure. although not having a specific shell might not keep them away completely. after all people who come from linux to unix/risc do that because they want something different i'd think.
there's not much sense in sticking to bash and gcc on every platform. makes it rather pointless

I'd rather have an up-to-date package for them to use if they so chose, rather then the ancient version on SGI Freeware being the only one.

I've patched the bash-4.3-source with through .29 (rebuilding with .30 on my octane now). I also have patched bash-4.2-sources (since neko_bash.tardist is 4.2). (Alternate download link from Google Drive)

armanox wrote: I'd rather have an up-to-date package for them to use if they so chose, rather then the ancient version on SGI Freeware being the only one.

of course

Proud to be a tcsh bigot, but I updated the TenFourFox bash to .30 anyway.

tcsh is good, but why not zsh? All the features of bash plus ksh plus some.

TeamBlackFox wrote: tcsh is good, but why not zsh? All the features of bash plus ksh plus some.

I'll speak as a confessed tcsh fan and former consultant/sysadmin - laziness. I took to csh when I first got access to 4.3BSD and SunOS 3 systems, and tcsh was already in circulation - years before I ever heard of zsh, even a couple years before the first version was written at Princeton. And if I have to deal with a system that doesn't have tcsh, it almost always has csh, and all I'd really notice I've lost is command line history and some prompt setting magic.

Now that all shells are everywhere by default, I suppose I'm just a dinosaur not to invest the time... Well, right: laziness.

In my case, tcsh works, is easy to get, doesn't change much, and I'm used to it. It hasn't cheesed me off enough to look at another shell.

Plus, as a product of the University of California, csh syntax is now wired into my brain.

I'm in the same boat as smj and Classy, even though I'm an east coast guy, not a California dude.

The first system I used in earnest used tcsh as the default shell, so that was the first shell I truly learned , instead of merely tinkered with. Now, tcsh just fits like a glove, and I can't remember the last time I needed to do something and I didn't know how to do it with tcsh. There may be shells that are better for some purposes or more feature rich than tcsh, but it's unlikely that the effort required to learn something as well as I currently know tcsh would actually reap sufficient rewards in increased productivity. I have bigger problems than shell selection these days.

Another Tenex C/ZSH fan here, too.

Trying to recall what the deal was with writing scripts running on csh. I seem to recall dire warnings of impending doom being circulated at one point, along with reminders to use !#/bin/sh.

SAQ wrote: Trying to recall what the deal was with writing scripts running on csh. I seem to recall dire warnings of impending doom being circulated at one point, along with reminders to use !#/bin/sh.

Yes, that was a very strongly held belief - but after 20 years I'm also having a little trouble remembering why . Based on some sketchy Googling, I'm guessing it's based on SUID use being risky because of how csh selects the home directory to read dot-files from at startup. There may also be something about how the environment is inherited, or how shell variables are initialized...?

If you've got time, it looks like Matt Bishop released an update in 2009 of a security review he did on UNIX in the 80s. Grab a copy of the PDF here . It has some detail on the SUID issue, at minimum.

setuid is dangerous on any shell script, not just those with csh. but csh is also poor for programming.

http://www-uxsup.csx.cam.ac.uk/misc/csh.html

On another note, I'm always amazed when an experienced UNIX user claims program x can't do y, when what he really means is, he never bothered to find out how. Most frequently, I encounter this around vi ("but I NEED vim to copy & paste!"), but... csh has always had command line history.

i use tcsh as a login shell, but i've never liked it for scripts. just a dim feeling that it wasn't very clean. when i had to write some scripts to recover a lost file, i used ksh.

kjaer wrote: but... csh has always had command line history.

More laziness - should I describe it as "interactive access to command history using editing key sequences?" That was what looked like a step backwards from what was available from VMS - doubtless other systems too (TOPS, TENEX, etc), but that was the mini OS I was using immediately prior, and I don't think any of the micro OSes I was using up to that time had it.

But yes, of course csh had command history - one of the primary reasons I preferred csh over sh in the first place was the history, as accessed through constructs like "!23" or "!-2" or "^sh^s" ...

kjaer wrote: setuid is dangerous on any shell script, not just those with csh. but csh is also poor for programming.

http://www-uxsup.csx.cam.ac.uk/misc/csh.html

a classic issue of dispute which, as that page shows, can get very emotional. but fortunately it's quite easy.
if what you wanna do works with csh and you wanna do it with csh then it's fine. otherwise use ksh.