rdd@wuphys.wustl.edu (Rakhal D. Dave) (04/29/91)
Another suggestion is to have direct root access from a user account in the GUI. Right now if I am installing something and happen to be user "me" and it suddenly becomes apparent that I need to set some files right in one of the root owned directories I have to go into "terminal" and change things with unix commands after becoming super user by using "su". What I'd like is to see an option in the user workspace menu, under tools maybe, called superuser. Choosing this option should cause the loginwindow to be displayed with root filled into the user field. On giving the password, without rearranging the workspace to match the root workspace and without halting any background processes it would be great to get all the root permissions to rearrange files. Rakhal Dave
scott@mcs-server.gac.edu (Scott Hess) (04/30/91)
In article <1991Apr29.082508.2376@wuphys.wustl.edu> rdd@wuphys.wustl.edu (Rakhal D. Dave) writes:
Another suggestion is to have direct root access from a user account in
the GUI. Right now if I am installing something and happen to be user "me"
and it suddenly becomes apparent that I need to set some files right in
one of the root owned directories I have to go into "terminal" and change
things with unix commands after becoming super user by using "su". What I'd
like is to see an option in the user workspace menu, under tools maybe,
called superuser. Choosing this option should cause the loginwindow to be
displayed with root filled into the user field. On giving the password,
without rearranging the workspace to match the root workspace and without
halting any background processes it would be great to get all the root
permissions to rearrange files. Rakhal Dave
This is a good idea, and I've often wanted to have it implemented.
The even worse case is when you need to actually run something as
root to get it to install correctly (for instance, to install
Improv in /LocalApps - you either run Installer as root, or change
the access privs on /LocalApps).
But, one thing I _don't_ want to see - stuff like UserManager and
the other programs in /NextAdmin. They prompt you for the root
password, and if you get it right, away you go. This, I think,
should not be - unless you are a member of the wheel group. Not
that I'm really overly worried about security, but that is a
concern - wheel group exists for a reason, and should be used as
it was meant to be!
[This is not to say that I've not taken advantage of this capability
at times, just to say that I shouldn't be able to! -scott]
In general, though, I'd like to have generalized cross-user access
privs, if I happen to be a wheel member with the root password.
Something like "Open as User...". This would make it alot easier
to manage stuff at times. In the best of all worlds, you could
also make the window that is in GOD mode be red, or something :-).
Later,
--
scott hess scott@gac.edu
Independent NeXT Developer GAC Undergrad
<I still speak for nobody>
"Simply press Control-right-Shift while click-dragging the mouse . . ."
"I smoke the nose Lucifer . . . Banana, banana."esht_cif@troi.cc.rochester.edu (Eran Shtiegman) (04/30/91)
In <1991Apr29.082508.2376@wuphys.wustl.edu> rdd@wuphys.wustl.edu (Rakhal D. Dave) writes: >Another suggestion is to have direct root access from a user account in >the GUI. Right now if I am installing something and happen to be user "me" >and it suddenly becomes apparent that I need to set some files right in >one of the root owned directories I have to go into "terminal" and change >things with unix commands after becoming super user by using "su". What I'd >like is to see an option in the user workspace menu, under tools maybe, >called superuser. Choosing this option should cause the loginwindow to be >displayed with root filled into the user field. On giving the password, >without rearranging the workspace to match the root workspace and without >halting any background processes it would be great to get all the root >permissions to rearrange files. Rakhal Dave This is a great idea! This happens to me at least once a day when I am using my next. Sometimes it is possible to launch the applications from the terminal window after su to root. But with some applications I can't do this like Installer that has a bunch of executables. Eran -- =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= - Eran Shtiegman - - email: esht_cif@troi.cc.rochester.edu - =-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
cafe@cbnewse.att.com (richard.dib) (05/01/91)
In article <1991Apr29.082508.2376@wuphys.wustl.edu>, rdd@wuphys.wustl.edu (Rakhal D. Dave) writes: > Another suggestion is to have direct root access from a user account in > the GUI. Right now if I am installing something and happen to be user "me" > and it suddenly becomes apparent that I need to set some files right in > one of the root owned directories I have to go into "terminal" and change > things with unix commands after becoming super user by using "su". What I'd > like is to see an option in the user workspace menu, under tools maybe, > called superuser. Choosing this option should cause the loginwindow to be > displayed with root filled into the user field. On giving the password, > without rearranging the workspace to match the root workspace and without > halting any background processes it would be great to get all the root > permissions to rearrange files. Rakhal Dave Actually it would be better if you could "su" to any other account, not only to "root". Richard Dib AT&T BL
bb@math.ufl.edu (Brian Bartholomew) (05/01/91)
In article <1991Apr29.082508.2376@wuphys.wustl.edu> rdd@wuphys.wustl.edu (Rakhal D. Dave) writes: > What I'd like is to see an option in the user workspace menu, under > tools maybe, called superuser. Choosing this option should cause the > loginwindow to be displayed with root filled into the user field. On > giving the password, without rearranging the workspace to match the > root workspace and without halting any background processes it would > be great to get all the root permissions to rearrange files. This is certainly do-able, but it strikes me as extremely messy and very dangerous. Mostly I think you would contradict many designed-in features of the "U*IX programming environment". What would you have a program do that has already chosen what to do based on your userid? Would you require code to be added to every U*IX program on the box to check occassionally to see if its uid has been changed to root? The idea of a big Frankenstein-style "Maintenance" switch is appealing, but I cannot visualize how to do it cleanly. -- "Any sufficiently advanced technology is indistinguishable from a rigged demo." ------------------------------------------------------------------------------- Brian Bartholomew UUCP: ...gatech!uflorida!beach.cis.ufl.edu!bb University of Florida Internet: bb@math.ufl.edu
DWN2@psuvm.psu.edu (05/01/91)
In article <1991May1.024534.4199@cbnewse.att.com>, cafe@cbnewse.att.com (richard.dib) says: >In article <1991Apr29.082508.2376@wuphys.wustl.edu>, rdd@wuphys.wustl.edu >(Rakhal D. Dave) writes: >> Another suggestion is to have direct root access from a user account in >> the GUI. >> [stuff deleted...] >Actually it would be better if you could "su" to any other account, not only >to "root". >Richard Dib >AT&T BL I would like to see this taken a little further (or approached a little differently ). I would like to see something in the browser menu more like LINK TO TTYxx that when activated gives the browser the same permissions as the terminal window and follows the current directory of the terminal window. If the LINK is made and the user issues su, then the browser is also su-ed to the new user, if the user types cd /.../... in the terminal, the browser reflects this too. If the directory in the browser is changed should terminal also change? I dunno, what do you think would be best? I think this idea could be extended much further. With Mach and the dynamic linking available this wouldn't be too big a deal, would it? Any other ideas along these lines? Dave +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + Dave Norton o e-mail to dwn2@psuvm.psu.edu + + Computational Solid Mechanics \ - + + Penn State University ()/ () % Engineering Visualization % + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
ptok@void.caltech.edu (phillip tokumaru) (05/01/91)
In article <BB.91May1005049@gomek.math.ufl.edu> bb@math.ufl.edu (Brian Bartholomew) writes: > In article <1991Apr29.082508.2376@wuphys.wustl.edu> > rdd@wuphys.wustl.edu (Rakhal D. Dave) writes: > > > What I'd like is to see an option in the user workspace menu, under > > tools maybe, called superuser. Choosing this option should cause the > > loginwindow to be displayed with root filled into the user field. On > > giving the password, without rearranging the workspace to match the > > root workspace and without halting any background processes it would > > be great to get all the root permissions to rearrange files. > > This is certainly do-able, but it strikes me as extremely messy and > very dangerous. Mostly I think you would contradict many designed-in > features of the "U*IX programming environment". What would you have a > program do that has already chosen what to do based on your userid? I think he (and I) just want to move around some files, set owners, permissions, you know, WorkspaceManager kind of stuff. A duplicate incarnation of the WorkspaceManager (with root login) would fit the bill. It could open up with a duplicate of the active user's Browser. It could even plaster warnings all over the window and put up messages like "Are you sure you want to XXXX as root? <cancel> <yes cr>" > Would you require code to be added to every U*IX program on the box to > check occassionally to see if its uid has been changed to root? The > idea of a big Frankenstein-style "Maintenance" switch is appealing, I call this logging in as root. > but I cannot visualize how to do it cleanly. I guess that depends on what you are trying to visualize.
smb3u@psysun1.acc.Virginia.EDU (Steven M. Boker) (05/01/91)
In article <1991May1.075944.11571@nntp-server.caltech.edu> ptok@void.caltech.edu writes: >In article <BB.91May1005049@gomek.math.ufl.edu> bb@math.ufl.edu (Brian >Bartholomew) writes: >> In article <1991Apr29.082508.2376@wuphys.wustl.edu> >> rdd@wuphys.wustl.edu (Rakhal D. Dave) writes: >> >> > What I'd like is to see an option in the user workspace menu, under >> > tools maybe, called superuser. Choosing this option should cause the >> >> idea of a big Frankenstein-style "Maintenance" switch is appealing, > >I call this logging in as root. > I think logging in as root is exactly right. However, this problem might be attacked from another angle. What you want is to be able to pop back to what you were doing before you logged in as root. I might have ten windows open and a number of Apps each with their own panels arranged just as I like them. Logging out of my account to log in to root destroys all of that setup work. What I would like to see is a way to freeze my workspace while I log out so that when I next log in everything is where I left it. This would make the process of a full workspace login to root relatively painless. For other tasks, it is pretty easy to bring up an editor as root and a shell as root already. Steve Boker smb@data.com "I left my .sig at home"
dejnsen@caen.engin.umich.edu (Nik Anthony Gervae) (05/02/91)
How 'bout a WM menu command like New File Viewer, but have it be Open New File Viewer as Root? The title bar could flash *very* slowly to indicate its "above normal" abilities, as could the title bar of any app opened from within it (for us monochrome people). The words "ROOT LAUNCH" could also appear at the far left of the title bar of any window opened from this viewer. That oughta be enough feedback. And of course docked apps would not be root. And also, root should have the ability to selectively enable this menu option for other groups/users. The ideas on marking a root-owned window are preliminary, but I think they're decent. Thick black borders is also an option. I think this would be a useful feature in release 3 (or maybe even 2.3 ;-). -- / Nik Gervae aka dejnsen@caen.engin.umich.edu | "It'll be finished next week, \ | CS/Linguistics stud. & NeRD at UM (go blow) | I promise!"--me | | | | | **When all else fails, bug someone who | "Just say an iguana chewed | \ knows (not me!). | up your textbook."--Jason Fox /
bill@gothamcity.jsc.nasa.gov (Bill Shirley) (05/02/91)
In article <1991Apr29.082508.2376@wuphys.wustl.edu>, rdd@wuphys.wustl.edu (Rakhal D. Dave) writes: |> What I'd |> > like is to see an option in the user workspace menu, under tools maybe, |> > called superuser. and maybe the option wouldn't be there unless you actually had permission (i.e. are a member of the correct group) to su to root. -Bill Shirley
louie@sayshell.umd.edu (Louis A. Mamakos) (05/02/91)
Do you *really* want yet another program (like the workspace manager!) with the ability to launch root shells or applications? Not me. I think there are too many suid-root programs on the machine already. When I've had to do sys-admin type stuff on the NeXT that I can't do from a shell prompt, I just su to root and launch the application from the shell. In my case, this is usually the Installer application. In summary: % su Password: secretword # /NextApps/Installer.app/Installer & # exit % This seems to work just fine. I suppose that a simple shell script could be written to accomodate the Foo.app style applications, but I don't have to do this often enough to worry about. If I'm going to be doing lots of administrative work, I just log in as root; do it; and log back out again.
mitroo@magnus.acs.ohio-state.edu (Varun Mitroo) (05/02/91)
In article <BB.91May1005049@gomek.math.ufl.edu> bb@math.ufl.edu (Brian Bartholomew) writes: >In article <1991Apr29.082508.2376@wuphys.wustl.edu> >rdd@wuphys.wustl.edu (Rakhal D. Dave) writes: > >> What I'd like is to see an option in the user workspace menu, under >> tools maybe, called superuser. Choosing this option should cause the >> loginwindow to be displayed with root filled into the user field. On >> giving the password, without rearranging the workspace to match the >> root workspace and without halting any background processes it would >> be great to get all the root permissions to rearrange files. > >This is certainly do-able, but it strikes me as extremely messy and >very dangerous. Mostly I think you would contradict many designed-in >features of the "U*IX programming environment". What would you have a >program do that has already chosen what to do based on your userid? >Would you require code to be added to every U*IX program on the box to >check occassionally to see if its uid has been changed to root? The >idea of a big Frankenstein-style "Maintenance" switch is appealing, >but I cannot visualize how to do it cleanly. > Why not just have an selection in the Workspace in the "View" option for "New Viewer as user..." - just like opening up a New Viewer. After typing in the username and correct password, this would open a new File Viewer "owned" by that user. -- You are young, they are old Control is all they've got to give Just live how you want to live Tiny things that make you slave Like a chain, an anchor to the bed of the sea