ric@arizona.edu (Ric Anderson) (06/07/89)
Anyone know the procedure needed to change the time zone from PDT to MST? I rumaged the man pages, but didn't find anything under the obvious key words. Thanks, Ric Ric Anderson Bitnet: Ric@Arizrvax Member of the Technical Staff Internet: ric@cs.arizona.edu Department of Computer Science AT&T: (602) 621-4048 University of Arizona Tucson, Arizona 85721
avie@wb1.cs.cmu.edu (Avadis Tevanian) (06/07/89)
In article <11408@megaron.arizona.edu> ric@arizona.edu (Ric Anderson) writes: >Anyone know the procedure needed to change the time zone from PDT to MST? Timezones are described from files in /etc/zoneinfo. In 0.9, create a link from /etc/zoneinfo/localtime to the correct file for your timezone. For MST, try /etc/zoneinfo/US/Mountain. Although you may want US/Arizona. In 1.0, Preferences will allow you to set the timezone in a MUCH more user-friendly way. -- Avadis Tevanian, Jr. (Avie) Manager, System Software Group / Chief Operating System Scientist NeXT, Inc. avie@cs.cmu.edu or avie@NeXT.com --
dorner@pequod.cso.uiuc.edu (Steve Dorner) (06/07/89)
In article <5139@pt.cs.cmu.edu> avie@wb1.cs.cmu.edu (Avadis Tevanian) writes: >In 1.0, Preferences will allow you to set the timezone in a MUCH more >user-friendly way. Does anybody besides me think that all the system-wide stuff that preferences lets you set ought to be accessible only to super-users? To wit: 1) system date and time 2) time zone (when incorporated) 3) boot device I for one am tired of changing the time on my system back to what it ought to be... -- Steve Dorner, U of Illinois Computing Services Office Internet: s-dorner@uiuc.edu UUCP: {convex,uunet}!uiucuxc!dorner IfUMust: (217) 244-1765
jgreely@oz.cis.ohio-state.edu (J Greely) (06/08/89)
In article <1178@garcon.cso.uiuc.edu> dorner@pequod.cso.uiuc.edu (Steve Dorner) writes: >In article <5139@pt.cs.cmu.edu> avie@wb1.cs.cmu.edu (Avadis Tevanian) writes: >>In 1.0, Preferences will allow you to set the timezone in a MUCH more >>user-friendly way. >Does anybody besides me think that all the system-wide stuff that >preferences lets you set ought to be accessible only to super-users? YES! This is a ridiculous misfeature, and it's downright dangerous in our environment. Gratuitously changing date and time can break cron scripts, accounting information, mail delivery, and backups (go ahead, try running daily backups on a machine that's spent the week in no less than three timezones), just for a start. Allowing any user to change the boot device is simply irresponsible (how long would it take *you* to take over any NeXT you can login to? Is your answer in minutes? Did you need to do anything outside of the window system?). >I for one am tired of changing the time on my system back to what it >ought to be... The worst part is that you have no way of finding out who caused the damage. If this behavior exists in 1.0 with no way for the administrator to disable it, no NeXTs will sit on our network. One will turn into a standalone demo machine, the other will be a printer, and no more will come into the department. Personally, I think the NeXT makes a nice high-end PC, but a lousy workstation. The fact that the company persists in giving away more privileges to *every* user reinforces that impression. If they want to make a personal computer, they should quit screwing up Unix to make it fit into their model. If they want to make a workstation, they need to supplement some of the design philosophy with reality checks. Enough idle torching. How *should* it work? I don't know. How would I *like* it to work? Simple. Believe it or not, you don't set date, time, and timezone very often, certainly not on a daily basis. These should be set in NetManager, in the local configuration window, because they're not "user preferences", they're system configuration. Sure, I might prefer to work on GMT (makes it easier to sleep in 'til noon), but the rest of the network that I'm part of is much more comfortable if I'm on EDT. Being five minutes off of the other machines is bad enough. As for setting boot device, I'd love to hear an argument as to why all users need to be able to set this. My response will most likely be hysterical laughter, but I *am* interested. Extra credit if your explanation holds up in a heterogenous network where the NeXT is to be trusted for NFS, mail, YP, and rlogin. -=- J Greely (jgreely@cis.ohio-state.edu; osu-cis!jgreely)
mrc@Tomobiki-Cho.CAC.Washington.EDU (Mark Crispin) (06/08/89)
I guess I don't understand, coming from an environment
(DEC-20/Xerox Lisp) only 8 months ago where it was assumed you
couldn't trust other machines and that even for things such as time
you made sure that what you got matched the concensus of many
machines.
There is no security against anyone who has physical access to
the console. Hell's bells, you can hit double-COMMAND-` to get an NMI
interrupt, halt the machine, and then boot it any way you want. I'm
no Unix wizard, but I know how to give myself superuser access to any
NeXT I can lay my hands on, even without an account.
I guess you could claim that this facility in Preferences opens
up such access to someone who has an account on the NeXT but doesn't
have access to the console (= logging in from another NeXT and then
doing "Preferences -Host <myhost>"). I dunno. If you let guys log
in on a NeXT but not use the console, maybe you'll protect /NextApps
so they can't get at it. Is anyone using NeXTs as ordinary Unix
timesharing boxes??
The bottom line remains that anyone can do anything on the
console, at least until NeXT comes out with a model that lets you lock
out the NMI interrupt or typein to the boot ROM (e.g. by key). So,
why not assume that anybody you allow to use your NeXTs is going to be
a responsible individual, albeit someone may need to be told what
*not* to do. Anyone you can't trust not to do bad things in
Preferences (once instructed on what not to do at your installation)
can't be trusted with physical access to a NeXT console either.
Mark Crispin / 6158 Lariat Loop NE / Bainbridge Island, WA 98110-2020
mrc@CAC.Washington.EDU / MRC@WSMR-SIMTEL20.Army.Mil / (206) 842-2385
Atheist & Proud / 450cc Rebel pilot -- a step up from 250cc's!!!
tabesaserarenakerebanaranakattarashii...kisha no kisha ga kisha de kisha-shita
sumomo mo momo, momo mo momo, momo ni mo iroiro aru
uraniwa ni wa niwa, niwa ni wa niwa niwatori ga iruavie@wb1.cs.cmu.edu (Avadis Tevanian) (06/08/89)
Please people, stay calm... Most people who buy a machine expect to be able to do whatever they want with their machine, including setting the time and date. If you need to administer someone's machine for them, then they will live by your rules (presumably). If this is the case, then just turn off the setuid bit for Preferences, for example. This may disable some other features that you wanted a user to retain (from Preferences), but most other things will still work (those that affect the defaults database, for example). -- Avadis Tevanian, Jr. (Avie) Manager, System Software Group / Chief Operating System Scientist NeXT, Inc. avie@cs.cmu.edu or avie@NeXT.com --
jgreely@previous.eng.ohio-state.edu (J Greely) (06/08/89)
In article <2333@blake.acs.washington.edu> mrc@Tomobiki-Cho.CAC.Washington.EDU (Mark Crispin) writes: > There is no security against anyone who has physical access to >the console. Hell's bells, you can hit double-COMMAND-` to get an NMI >interrupt, halt the machine, and then boot it any way you want. I'm >no Unix wizard, but I know how to give myself superuser access to any >NeXT I can lay my hands on, even without an account. Yup, and that's one major reason we won't buy them. We currently use Suns in both student labs and faculty offices, all sharing the same filesystems. What you might call a "hostile environment". The same problems exist on our suns, but with 4.x, if the console is not marked secure you can't boot single-user without the root password, and root logins are not permitted. NeXT has done part of that, but marking the console as not secure does nothing to prevent arbitrary users from booting single-user. Oops. There are other fun things that can be done with the ROM monitor, most of which are too complex for the average undergrad, but the combination of: a) user-creatable system disks, b) magical ownership of all files on an optical, and c) the ability to set the boot device in a "user-friendly fashion", allows people to break into the machine without ever leaving the user-friendly, bells-and-whistles window system. Bad enough having people breaking in, but at least with most systems they have to know *something* to do it! NeXT has created "security holes for the rest of us." >Is anyone using NeXTs as ordinary Unix >timesharing boxes?? I use the NeXT on my desk as a workstation, interacting with our network as a "trusted peer". It exports a filesystem, it mounts 56 file systems from other hosts, it uses the same password and group files, and looks like just another Unix box to other machines. The only reason I allow it to operate in this fashion is because the console sits in my office, over which I have some reasonable guarantees about security. In contrast, we have labs that contain large numbers of Suns for student use, and access to their consoles doesn't lower our security drastically. I'd like to make a machine like the NeXT available for use by ordinary people, but I don't trust it in a public location. > The bottom line remains that anyone can do anything on the >console, at least until NeXT comes out with a model that lets you lock >out the NMI interrupt or typein to the boot ROM (e.g. by key). Sun's solution to the ROM monitor problem was to make replacement chips that required a password to do anything other than continue. This would be acceptable for solving that problem (and, I think, preferable to adding a key). >So, >why not assume that anybody you allow to use your NeXTs is going to be >a responsible individual, albeit someone may need to be told what >*not* to do. Anyone you can't trust not to do bad things in >Preferences (once instructed on what not to do at your installation) >can't be trusted with physical access to a NeXT console either. Well, let's see. Of the 2000 or so people who have accounts on our Unix machines, the number I trust "not to do bad things" is about 50. This is equivalent to the support staff and system operators. With the fairly high turnover in population here (approximately 25% every 3 months), there will always be people who don't know what actions are "disrecommended", or can't be trusted to not do them. Easier to just not buy the NeXT, which, right now, is the solution we'd choose. -=- J Greely (jgreely@cis.ohio-state.edu; osu-cis!jgreely)
avie@wb1.cs.cmu.edu (Avadis Tevanian) (06/08/89)
In article <51400@tut.cis.ohio-state.edu> J Greely <jgreely@cis.ohio-state.edu> writes: > There are other fun things that can be done with the ROM monitor, 1.0 ROMS will have optional hardware protection. -- Avadis Tevanian, Jr. (Avie) Manager, System Software Group / Chief Operating System Scientist NeXT, Inc. avie@cs.cmu.edu or avie@NeXT.com --
dorner@pequod.cso.uiuc.edu (Steve Dorner) (06/08/89)
In article <2333@blake.acs.washington.edu> mrc@Tomobiki-Cho.CAC.Washington.EDU (Mark Crispin) writes: > The bottom line remains that anyone can do anything on the >console, at least until NeXT comes out with a model that lets you lock >out the NMI interrupt or typein to the boot ROM (e.g. by key). No disagreement there; I've complained about that before. > ... Anyone you can't trust not to do bad things in >Preferences (once instructed on what not to do at your installation) >can't be trusted with physical access to a NeXT console either. I agree that there is NO protection against malicious damage. But to put the time, etc, in such a prominent application, with such tempting buttons and controls just begs people (even responsible people who would NEVER do something deliberately wrong to my system) to play with them. In fact, the most knowledgeable among them do so with impunity, figuring that "This can't POSSIBLY set the real system time, that would be ridiculous." And that little calendar display? Everybody thinks its some sort of appoint- ment book, and tries clicking on the buttons. Educating regular users is one thing. But you simply can't educate everyone BEFORE they sit down at a cube. And, posting a list of "Fifteen Bad Things You Should Not Do" seems like a dangerous proposition; surely there is some _small_ validity to "security through obscurity". -- Steve Dorner, U of Illinois Computing Services Office Internet: s-dorner@uiuc.edu UUCP: {convex,uunet}!uiucuxc!dorner IfUMust: (217) 244-1765