apippin@polyslo.CalPoly.EDU (Pinhead@Spikes) (06/27/89)
I am attempting to 'su' to root, and it gives me a permission denied. To what PPO does my account need? As of now it is andy.staff.none; root's is root.staff.none. I am on a DN3500 running SR10.1. Thanks in advance. a. -- Andy Pippin "Beauty is only a lightswitch away..." apippin@polyslo.CalPoly.EDU "Thirty-one. SOCIAL!!!"
kts@quintro.UUCP (Kenneth T. Smelcer) (06/28/89)
In article <12151@polyslo.CalPoly.EDU> apippin@polyslo.CalPoly.EDU (Pinhead@Spikes) writes: > > I am attempting to 'su' to root, and it gives me a permission denied. >To what PPO does my account need? As of now it is andy.staff.none; root's >is root.staff.none. > > I am on a DN3500 running SR10.1. Thanks in advance. > >a. >-- >Andy Pippin "Beauty is only a lightswitch away..." >apippin@polyslo.CalPoly.EDU "Thirty-one. SOCIAL!!!" At SR10.1, you must belong to group "wheel" in order to 'su' to root. This is a convention direct from Berkeley. Does anyone know of a way to change this? Something else I've noticed with su and root login in general. The first time you log in as root, either from the display or 'su', it takes forever to start up. It doesn't seem to do any special disk access or eat processor time, it just sits for a while. After the first time (2 --> oo) everything is fine and is quite fast. Any ideas? BTW, my system is the same as above. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= Ken Smelcer Quintron Corp. quintro!kts@lll-winken Quincy, IL tiamat!quintro!kts@uunet
khaw@pplace.COM (Mike Khaw) (06/29/89)
> Something else I've noticed with su and root login in general. The
Other oddities about SR10.x root login:
I have to do "stty -tabs" to get ls listings to line
up right, but I don't have to do that for non-root
logins. Putting "stty -tabs" in .cshrc doesn't help.
Hitting the HELP key only gets you generic Domain_OS
help, but not man files. Non-root accounts get both
Domain_OS help and man files with the HELP key.
(Not-necessarily-root) Domain_OS vi weirdities (no flames
about using vi, please -- I have to work on many different Unix
machines and it's not worth the aggravation to me to learn the DM
editor):
Occasionally, if you open a shell window and start up
vi immediately, vi prints some complaint about not
knowing what an apollo_<mumble> terminal type is, goes
into line mode and then some state where it's hung.
If I kill the vi process and then again try vi in the
same window, it works fine.
Operations like "!G sort" to sort the contents of vi's
buffer work but cause 2 lines of "ioctl: not a typewriter"
to be inserted ahead of the current line.
Once in a while, ^Z out of vi hangs the shell window.
(Must be a keymap problem ...) ^^ (control-caret) doesn't
do anything (it's supposed to take you to the previous file
you were editing). I also wish the bsd environment did
proper keymaps for ^u (kill line) and ^w (kill word).
Mike Khaw
--
ParcPlace Systems, 1550 Plymouth St., Mountain View, CA 94043 415/691-6749
Domain=khaw@parcplace.com, UUCP={uunet,sun,decwrl}!parcplace!khawjoshua@athertn.Atherton.COM (Flame Bait) (06/29/89)
In article <366@quintro.UUCP> kts@quintro.UUCP (Kenneth T. Smelcer) writes: >At SR10.1, you must belong to group "wheel" in order to 'su' to root. >This is a convention direct from Berkeley. Does anyone know of a way >to change this? Are you sure this came from Berkeley? I've used several versions of BSD software, and have never heard of this before. I know that SunOS 3.X and Ultrix 2.X (both dirived from BSD) do not have this requirement. In the past I've used Ultrix 1.X, and Mt. Xinu 4.1 and 4.2, and I do not think either of them had this requirement either. If it did come from Berkeley, it must be new with 4.3 BSD. As for fixing it, try doing something tricky with shell scripts. Have a shell script which is setuid and owned by wheel; use it to call the "real" su. This will do bad things for security, but that's life. What else is group wheel used for? If nothing, just add everyone to it. Look for public domain versions of su. Have fun. Joshua Levy -------- Quote: "If you haven't ported your program, it's not Addresses: a portable program. No exceptions." joshua@atherton.com OR sun!athertn!joshua OR {backbone}!{decwrl!hpda}!athertn!joshua work:(408)734-9822 home:(415)968-3718
GBOPOLY1@NUSVM.BITNET (fclim) (06/29/89)
In article <5892@joshua.athertn.Atherton.COM> joshua%athertn%pyramid%oliveb .uucp@apple.com (Flame Bait) writes >In article <366@quintro.UUCP> kts@quintro.UUCP (Kenneth T. Smelcer) writes: >>At SR10.1, you must belong to group "wheel" in order to 'su' to root. >>This is a convention direct from Berkeley. Does anyone know of a way >>to change this? > >As for fixing it, try doing something tricky with shell scripts. Have >a shell script which is setuid and owned by wheel; use it to call the "real" >su. This will do bad things for security, but that's life. What else >is group wheel used for? If nothing, just add everyone to it. Look for >public domain versions of su. Ken sez that wheel is a group id and not a user id. In this case, the shell script must have several bits set. Firstly, it needs to be owned by root (I don't think wheel owning it will work). Then it must have its group id set to wheel. Finally the setuid and setgid permission modes must be set. ie % /etc/chown root shell-script % /bin/chgrp wheel shell-script % chmod 6755 shell-script % ls -l shell-script -rwsr-sr-x ? root .... % ls -lg shell-script -rwsr-sr-x ? wheel .... fclim --- gbopoly1 % nusvm.bitnet @ cunyvm.cuny.edu computer centre singapore polytechnic dover road singapore 0513.
wescott@LNIC1.HPRC.UH.EDU (Andrew M. Wescott) (06/29/89)
So what is wrong with having to belong to group "wheel" in order to su root? I miss the point entirely. Let the sysadm add whoever to wheel from edrgy, give them the password, and be done with it. There is one interesting hitch though... Say I am logged on to an Apollo console as myself, and then I decide to su root. Well now I can do things like run edrgy, kill processes, and the like. But guess what I can't do? I can't EDIT files owned by root.staff.none with -rwxr-xr-x protection. Now here's the real clincher: When I dial up from home and decide to su root, I am able to edit these\ same files with no problem. That confuses me. Andrew Wescott University of Houston
pato@apollo.COM (Joe Pato) (06/30/89)
When using the Berkeley derived version of su, the user must be a member of the
wheel group (actually of group 0) to be allowed to "su" to root.
Joe Pato
Apollo Computer A Subsidiary of Hewlett-Packard
NSFNET: pato@apollo.com UUCP: ...{attunix,uw-beaver,brunix}!apollo!patoGBOPOLY1@NUSVM.BITNET (fclim) (06/30/89)
In article <8906291414.AA04731@lnic1.hprc.uh.edu> Andrew M. Wescott <wescott@lnic1.hprc.uh.edu> writes >So what is wrong with having to belong to group "wheel" in >order to su root? I miss the point entirely. Let the sysadm >add whoever to wheel from edrgy, give them the password, and >be done with it. Say what? We are talking about su, Andrew, ability to turn into Superuser in a single bound. We might as well give root's passwd to selected people and let them use login instead of su. >Say I am logged on to an Apollo console as myself, and then I >decide to su root. Well now I can do things like run edrgy, >kill processes, and the like. But guess what I can't do? >I can't EDIT files owned by root.staff.none with -rwxr-xr-x >protection. Now here's the real clincher: When I dial up >from home and decide to su root, I am able to edit these >same files with no problem. That confuses me. At SR9.7, /doc/domain_ix.release_notes sez that there are limitations when you su/login to a different user. The change in the USER environme environment variable is not communicated to the DM. So EDIT, cv, etc will not work if the new user does not have the acl rights. The notes suggest using ed, ex or vi for editing purposes. In article <442098a6.1dc6c@apollo.COM> pato%apollo.uucp@eddie.mit.edu (Joe Pato) writes >When using the Berkeley derived version of su, the user must be a membe of the >wheel group (actually of group 0) to be allowed to "su" to root. Unless there is explicit code to check the *real* group id with "wheel", I believe, any user can su to root if your sys_admin login in as root and do % chgrp wheel /bin/su % chmod 6755 /bin/su Anybody running su will have effective group id set as "wheel". This beats having to put all those users who will su to root sometimes in the future in the same group as wheel. Since su prompts for passwds, it is all right to set the setgid on. fclim --- gbopoly1 % nusvm.bitnet @ cunyvm.cuny.edu computer centre singapore polytechnic dover road singapore 0513.
krowitz@RICHTER.MIT.EDU (David Krowitz) (06/30/89)
Oddly enough, I have both an Alliant FX/40 running BSD4.2 and and I can 'su' to root on both sets of machines *without* being a member of the 'wheel' group. There must be some other fairly wide-spread mechanism for setting up this access. All of our systems are standard distributions. We have not fooled with anything in the BSD packages that came with the machines. -- David Krowitz krowitz@richter.mit.edu (18.83.0.109) krowitz%richter@eddie.mit.edu krowitz%richter@athena.mit.edu krowitz%richter.mit.edu@mitvma.bitnet (in order of decreasing preference)
pato@APOLLO.COM (06/30/89)
Oddly enough, I have both an Alliant FX/40 running BSD4.2 and
and I can 'su' to root on both sets of machines *without*
being a member of the 'wheel' group. There must be some
other fairly wide-spread mechanism for setting up this
access. All of our systems are standard distributions.
We have not fooled with anything in the BSD packages
that came with the machines.
-- David Krowitz
krowitz@richter.mit.edu (18.83.0.109)
krowitz%richter@eddie.mit.edu
krowitz%richter@athena.mit.edu
krowitz%richter.mit.edu@mitvma.bitnet
(in order of decreasing preference)
This behavior is part of BSD 4.3 not BSD 4.2 (therefore it exists in DOMAIN/OS
sr10.x and not in DOMAIN/IX sr9.X)
Joe Pato
Apollo Computer A Subsidiary of Hewlett-Packard
NSFNET: pato@apollo.com UUCP: ...{attunix,uw-beaver,brunix}!apollo!pato
-------pato@APOLLO.COM (07/01/89)
In-Reply-To: krowitz@richter (David Krowitz), fri, 30 jun 89 09:47:47
Oddly enough, I have both an Alliant FX/40 running BSD4.2 and
and I can 'su' to root on both sets of machines *without*
being a member of the 'wheel' group. There must be some
other fairly wide-spread mechanism for setting up this
access. All of our systems are standard distributions.
We have not fooled with anything in the BSD packages
that came with the machines.
-- David Krowitz
krowitz@richter.mit.edu (18.83.0.109)
krowitz%richter@eddie.mit.edu
krowitz%richter@athena.mit.edu
krowitz%richter.mit.edu@mitvma.bitnet
(in order of decreasing preference)
This behavior is part of BSD 4.3 not BSD 4.2 (therefore it exists in DOMAIN/OS
sr10.x and not in DOMAIN/IX sr9.X)
Joe Pato
Apollo Computer A Subsidiary of Hewlett-Packard
NSFNET: pato@apollo.com UUCP: ...{attunix,uw-beaver,brunix}!apollo!pato
-------GBOPOLY1@NUSVM.BITNET (fclim) (07/01/89)
"It is better to keep your mouth shut and let people think you're a fool than to open it and remove all doubts." I have done it this time; it's confirmed -- I'm a fool. Yesterday, I wrote > In article <8906291414.AA04731@lnic1.hprc.uh.edu> Andrew M. Wescott > <wescott@lnic1.hprc.uh.edu> writes > > >So what is wrong with having to belong to group "wheel" in > >order to su root? I miss the point entirely. Let the sysadm > >add whoever to wheel from edrgy, give them the password, and > >be done with it. > > Say what? We are talking about su, Andrew, ability to turn into > Superuser > in a single bound. We might as well give root's passwd to selected > people > and let them use login instead of su. What am I talking about? Of course, you have to give away the passwd to allow them to su to root. But, Andrew, *don't* put those selected few in the same group as "wheel" I have created 2 accounts for myself. Using edacct, I add fclim (per) staff (proj) cc (org) and fclim (per) sys_admin (proj) none (org) in that order. Normally, when I log in, it will be fclim.staff.cc which is an ordinary account. When I test out ideas (via shell scripts or otherwise), I will not accidently delete system files. After certifying these scripts to be bug free, I logs in as fclim.sys_admin to run the scripts as sysadmin Adding users to "wheel" group will give these users power to edit/delete files owned by root. If foo has the permission modes rwxr-xr-x root (owner) wheel (group) then these users will not be able to edit/delete foo. However, if we have for bar rwxrwxr-x root (owner) wheel (group) then bar may be accidently deleted. The users need not su to root to edit/delete bar. Have a happy 4th of July. fclim --- gbopoly1 % nusvm.bitnet @ cunyvm.cuny.edu computer centre singapore polytechnic dover road singapore 0513.
wescott@LNIC1.HPRC.UH.EDU (07/02/89)
Well basically I'm a tyrant, as I don't let anyone have SU privilege. That's one solution! Andrew Wescott
pcc@apollo.COM (Peter Craine) (07/03/89)
In article <552@parcplace.pplace.COM> khaw@pplace.COM (Mike Khaw) writes: > > I have to do "stty -tabs" to get ls listings to line > up right, but I don't have to do that for non-root > logins. Users probably have "ts 9 -r" in their startup_dm.<display>. Put one in root's startup_dm and this will probably go away. > > Hitting the HELP key only gets you generic Domain_OS > help, but not man files. Non-root accounts get both > Domain_OS help and man files with the HELP key. Sounds like key definitions. Check out one non-root account's key definitions and do appropriate 'kd's for root. > >(Not-necessarily-root) Domain_OS vi weirdities (no flames >about using vi, please -- I have to work on many different Unix >machines and it's not worth the aggravation to me to learn the DM >editor): > > Occasionally, if you open a shell window and start up > vi immediately, vi prints some complaint about not > knowing what an apollo_<mumble> terminal type is, goes > into line mode and then some state where it's hung. > If I kill the vi process and then again try vi in the > same window, it works fine. Sounds like it's time for the generic vi problem-fixer. 1) log on as root 2) rm -rf /dev/ttyp* /dev/pty* 3) /etc/mkdev /dev pty 4) reboot the node. This clears up the majority of vi problems. For anything else, I'd call the 800 number. > > (Must be a keymap problem ...) ^^ (control-caret) doesn't > do anything (it's supposed to take you to the previous file > you were editing). I also wish the bsd environment did > proper keymaps for ^u (kill line) and ^w (kill word). Use your own keydefs. Try (in the command window) kd ^u cms;tl;xd line_del ke This will delete the line that your cursor is on. [this is the current keydef for the <line delete> key. >Mike Khaw Peter Craine, NACS I know I put my .signature with the appropriate disclaimer in here somewhere!
thallem@guille.ece.orst.edu (Mike Lohmeyer) (07/07/89)
In article <8907011801.AA09885@lnic1.hprc.uh.edu> wescott@LNIC1.HPRC.UH.EDU writes: >Well basically I'm a tyrant, as I don't let anyone have SU >privilege. That's one solution! > The idea of the group wheel is for people who are suppose to have access to some system admin stuff. In otherwords, wheel members can sometimes modify files or run programs for system administration that regular users cannot. Wheel is sort of a support group. My solution to the problem was to not use su at all. I don't like the program because sometimes I don't trust the way it sets up the enviroment (home dir, etc.) Instead, I got the sources for su2 from our Microvax II and compiled if the the Apollo systems. For those that don't know, su2 is very similar to su in that it allows users to become root. The difference is that when the user types su2, they are asked to enter their own password, not the root password. That way, no users except the real superuser know the root password. The other nice part about su2 is that the only people who can do an su2 are the users who's names are entered in a file called super-users. These names can be added or removed at any time easily to grant or revoke super user access to users. I should say that I am using SR9.7, not 10.x. I don't know if 10.x has su2 as a standard part of the OS. If not, it should. Su2 is a fairly standard program, and invaluable too. Mike Lohmeyer thallem@ece.orst.edu Oregon State University (503) 645-5504 Electrical and Computer Engineering Department