animal@unix.SRI.COM (Chan Wilson) (09/13/90)
Odd, odd odd: >zaphod:/pub/Macstuff/lib/aux_asm[40] su >su: Sorry >zaphod:/pub/Macstuff/lib/aux_asm[41] su root >su: Sorry >zaphod:/pub/Macstuff/lib/aux_asm[42] su Guest >zaphod: su >su: Sorry >zaphod: logout >zaphod:/pub/Macstuff/lib/aux_asm[43] rlogin loop -l Guest > >****************************************************************************** >* * >* W E L C O M E T O A / U X * >****************************************************************************** > >zaphod.Guest 1 % su >Password: >zaphod.Guest ! # exit I can su to root from the Guest account. I can't su to root from my account. I'm fairly certain that it has to do with the fact that the password file on Zaphod (a/ux) uses YP (NIS), as does the group file. Trouble is, the man page for su has no mention of where su actually looks to determine who can su, and the sunos man page for su isn't great help either. And, I can't trace su to see what it's doing.... WHERE'S MY DOCUMENTATION?????????? Thanks for any help... --Chan Chan Wilson SRI Intl. Network Information Systems Center 333 Ravenswood Ave., EK289 Internet: cwilson@nisc.sri.com Menlo Park, CA., 94025 Phone: (415)859-5921
ron@afsg.apple.com (Ron Flax) (09/13/90)
In article <16167@unix.SRI.COM> cwilson@nisc.sri.com writes: >Odd, odd odd: >I can su to root from the Guest account. I can't su to root >from my account. Chan, What shell are you using with these two accounts? Would one of them happen to be tcsh? From Ohio State maybe? If so, it's broken! The BSD signal compat stuff was not done correctly in their version and you cannot open /dev/tty, which is what getpass() tries to do inside of su. There is a fixed (working) version of tcsh in ~ftp/pub on afsg.apple.com. -- Ron Flax ron@afsg.apple.com Apple Federal Systems Group
anderson@csli.Stanford.EDU (Steve Anderson) (09/15/90)
In article <447@afsg.apple.com>, ron@afsg.apple.com (Ron Flax) writes: > There is a fixed (working) version of tcsh in ~ftp/pub on > afsg.apple.com. I had also noticed that the OSU version of tcsh was broken. Thanks for posting a fixed copy. The tcsh on afsg.apple.com works fine, except for one thing: when I login with this as my shell, it doesn't run my .login, apparently. The same thing happens with bash as my login shell. Only when my default shell is sh or csh is .login run. Perhaps this is related to the fact that with bash as my shell, I couldn't set the X11 screen depth to 8 in ~/.X11 as documented in the manual. I fixed that by editing the basic X startup script, but I shouldn't have had to. Is there some way in which shells other than csh and sh are not being told about where a user's home directory is at startup? If so, how can I fix this? If not, what else might be going on? Steve Anderson anderson@sapir.cog.jhu.edu anderson@csli.stanford.edu
rmtodd@servalan.uucp (Richard Todd) (09/16/90)
anderson@csli.Stanford.EDU (Steve Anderson) writes: >The tcsh on afsg.apple.com works fine, except for one thing: when I >login with this as my shell, it doesn't run my .login, apparently. The >same thing happens with bash as my login shell. Only when my default >shell is sh or csh is .login run. Hmm. Is your default session type the Mac 32-bit or 24-bit session? I've noticed that for some reason when logging in to that type of session, when your shell is tcsh, that your .login is not executed. Looks like CommandShell is doing something bizarre and isn't prepared to handle shells besides sh and csh; a quick strings of CommandShell shows the strings "/bin/sh -i" and "/bin/csh -i". (Hmm...anybody out there using ksh and experiencing this problem?) Quick workaround: instead of logging into the Mac 32-bit or 24-bit env. from the Login window, log into the console emulator and start the Mac environment by hand with the "mac32" or "mac24" command. This has the additional advantage that when you find out that your favorite Mac app wasn't 32-bit clean after all and it takes MacOS down in a flaming heap of rubble, you don't get logged out and have to log in again, you just get returned to your shell prompt on the console. (Note: the default scripts for mac32 and mac24 don't do a screenrestore after they complete, so when mac32 or mac24 exits, it doesn't restore the screen to console-emulator (1-bit) mode. I recommend you use these aliases: alias mac32 "mac32; screenrestore" alias mac24 "mac24; screenrestore" to get the desired effect.) -- Richard Todd rmtodd@uokmax.ecn.uoknor.edu rmtodd@chinet.chi.il.us rmtodd@servalan.uucp
ron@afsg.apple.com (Ron Flax) (09/17/90)
In article <1990Sep15.201545.5311@servalan.uucp> rmtodd@servalan.uucp (Richard Todd) writes: >anderson@csli.Stanford.EDU (Steve Anderson) writes: >>The tcsh on afsg.apple.com works fine, except for one thing: when I >>login with this as my shell, it doesn't run my .login, apparently. The >>same thing happens with bash as my login shell. Only when my default >>shell is sh or csh is .login run. > > Hmm. Is your default session type the Mac 32-bit or 24-bit session? >I've noticed that for some reason when logging in to that type of session, >when your shell is tcsh, that your .login is not executed. Looks like Actually, what's happening is that /etc/Login exec's your shell with the -c argument and calls /mac/bin/mac{32,24} which means the shell in your first CommandShell window is not really a login shell. So that shell doesn't source your .login by design. -- Ron Flax ron@afsg.apple.com Apple Federal Systems Group