amir@s.ms.uky.edu (Amir Sadr) (02/12/91)
I've just noticed that during Ksh, becoming super user via /bin/su will change the owner and group ID of $HISTFILE (in my case $HOME/.kshistory) to root. Once I become a regular user again, the group and owner ID of the history file however remain as root. This will, I assume, force Ksh to keep a history of my session in core (since I can still walk through my commands). But once I terminate Ksh and restart another one, not only the commands issued after su are lost, but the new Ksh no longer has permission to write to $HISTFILE. And thus even though no error or warning message is given, any recorded history is lost once a Ksh session is terminated. History files should be read and write protected from others and in fact that is the way Ksh creates them if they do not exist. I suppose this problem could be ridden if I allow others write permission to my history file, but I don't think this is reasonable. Or I could just avoid become super user by using /bin/su and instead login as root. Has anyone else noticed this phenomenon, or is it just me doing something wrong? I am running version 3.51m and I'd be interested to hear if others have experienced the same? I can't recall, but I think a new Ksh was delivered as part of 3.51m upgrade. Did the 3.51a version do this too? I hadn't noticed this then? Can this some how be patched? Thank you- -- - Amir Sadr, Dept. of Computer Science amir@ms.uky.edu - University of Kentucky amir@UKMA.BITNET - Lexington, KY 40506-0027 [rutgers,uunet]!ukma!amir --
dnichols@ceilidh.beartrack.com (DoN Nichols) (02/13/91)
In article <1991Feb12.055727.23183@ms.uky.edu> amir@s.ms.uky.edu (Amir Sadr) writes: >I've just noticed that during Ksh, becoming super user via /bin/su will >change the owner and group ID of $HISTFILE (in my case $HOME/.kshistory) >to root. Once I become a regular user again, the group and owner ID of the >history file however remain as root. This will, I assume, force Ksh to keep >a history of my session in core (since I can still walk through my commands). >But once I terminate Ksh and restart another one, not only the commands >issued after su are lost, but the new Ksh no longer has permission to >write to $HISTFILE. And thus even though no error or warning message is >given, any recorded history is lost once a Ksh session is terminated. > [...] > >Has anyone else noticed this phenomenon, or is it just me doing something >wrong? I am running version 3.51m and I'd be interested to hear if others >have experienced the same? I can't recall, but I think a new Ksh was >delivered as part of 3.51m upgrade. Did the 3.51a version do this too? >I hadn't noticed this then? Can this some how be patched? Thank you- Yes, it happened to me, too! I had given up using su(1), and just logged out and back in when needing root powers. This was with the new ksh from the fixdisk2.0. I had been having problems with some code failing in some Cnews scripts unless run under sh(1). I had read mention recently of the ksh on osu-cis being the better one to use for the unix-pc, so I snarfed it. (KSH+IN.Z) Not only did it execute the Cnews code properly, but it also didn't give the ownership change of .kshistory. I had been trying to post the very question you posted just after installing Cnews, and the system kept rejecting my articles because 'comp.sys.3b1' wasn't in the active file (when I KNEW it was there - I had PUT it there :-). By the time I generated a workaround for the Cnews problem, I had more pressing things to post about. After getting the new ksh from osu-cis, and verifying that it fixed the Cnews problem, I tried the su, just for fun, and was overjoyed to find that problem fixed. If you have ftp access through some system at work or whatever, ftp to 'cheops.cis.ohio-state.edu' (128.146.8.62), set binary mode, and 'get ~/pub/att7300/STORE/KSH+IN.Z'. It comes with documentation which assumes that you'll be installing it as '/bin/sh'. I have found no need to do that, since everything for which I wish to use it, lets me specify the login shell as '/bin/ksh' with no problems. (I'm running 3.51m). Good Luck DoN. -- Donald Nichols (DoN.) | Voice (Days): (703) 664-1585 D&D Data | Voice (Eves): (703) 938-4564 Disclaimer: from here - None | Email: <dnichols@ceilidh.beartrack.com> --- Black Holes are where God is dividing by zero ---
krohn@cellar.bae.bellcore.com (Eric Krohn) (02/13/91)
In article <1991Feb13.005632.19801@ceilidh.beartrack.com>, dnichols@ceilidh.beartrack.com (DoN Nichols) writes: |> In article <1991Feb12.055727.23183@ms.uky.edu> amir@s.ms.uky.edu (Amir Sadr) writes: |> >I've just noticed that during Ksh, becoming super user via /bin/su will |> >change the owner and group ID of $HISTFILE (in my case $HOME/.kshistory) |> >to root. Once I become a regular user again, the group and owner ID of the |> >history file however remain as root. This will, I assume, force Ksh to keep |> >a history of my session in core (since I can still walk through my commands). |> |> Yes, it happened to me, too! I had given up using su(1), and just |> logged out and back in when needing root powers. This was with the new ksh |> from the fixdisk2.0. .... |> After getting the new ksh from osu-cis, and verifying that it fixed |> the Cnews problem, I tried the su, just for fun, and was overjoyed to find |> that problem fixed. Getting a working ksh is obviously the preferred solution. However, I've also used a technique of switching HISTFILE based on user name (even with a working ksh :-). I run su cplus -c "exec $bin/myksh" where myksh runs id(1) to get the new user name and does HISTFILE=$HOME/history/$ID exec ksh I will also do HISTFILE=$HOME/history/parser exec ksh when I want to work on my parser. Advantages: * different user IDs use different history files (my $HOME/history directory is mode 777), so no permission problems. * different user IDs and projects maintain different saved history. When I'm root, or cplus, I usually want to run different commands than when I'm me. When I'm working on my parser, I want to search for the make command germane to it rather than some other make for a different piece of software. Disadvantages: * You cannot share history file contents. (That's what cut and paste are for!) -- Eric J. Krohn krohn@bae.bellcore.com or uunet!bellcore!bae!krohn Bell Communications Research, 444 Hoes Ln, Piscataway, NJ 08854
kak@hico2.UUCP (Kris A. Kugel) (02/15/91)
In article <1991Feb12.055727.23183@ms.uky.edu>, amir@s.ms.uky.edu (Amir Sadr) writes:
[ksh with su turns off the user's permission to write ksh history]
I always find it a pain to go back to the old shell now that I'm used to ksh.
Yes, I've had this problem. As a result, I've got the root default shell
(in /etc/passwd) set to /bin/sh, since that won't change history.
The culprit is the HISTFILE variable, you have to change that
before you su. Maybe something like this:
"HISTFILE=/tmp/.suhistory /bin/su"
I have a vague recollection that this will spawn off the command
with the HISTFILE variable changed in its environment, but will
not change HISTFILE in the current environment.
* * * * * * * * * * (two minutes pass) * * * * * * * * * *
I just tried something similar to this,
"HISTFILE=/tmp/.suhistory /bin/su root -c ksh"
(some futzing to get ksh instead of sh for my su)
This didn't change HISTFILE in the current environment,
didn't change my history file permissions or ownership
but did keep a history (numbered from one)
maybe you can alias su to the earlier verion above and use su'd ksh that way.
Jeez, thanks for asking, I'd just been living with the sub-optimal /bin/sh
solution up to now. Now, I've got something better . . . .
Kris A. Kugel
( 908 ) 842-2707
uunet!tsdiag.ccur.com!hico2!kak
{daver,ditka,zorch}!hico2!kak
internet: kak@hico2.westmark.comjon@jonlab.UUCP (Jon H. LaBadie) (02/16/91)
In article <1991Feb13.005632.19801@ceilidh.beartrack.com>, dnichols@ceilidh.beartrack.com (DoN Nichols) writes: > In article <1991Feb12.055727.23183@ms.uky.edu> amir@s.ms.uky.edu (Amir Sadr) writes: > >I've just noticed that during Ksh, becoming super user via /bin/su will > >change the owner and group ID of $HISTFILE (in my case $HOME/.kshistory) > >to root. Once I become a regular user again, the group and owner ID of the > >history file however remain as root. > > > Yes, it happened to me, too! I had given up using su(1), and just > logged out and back in when needing root powers. > ... . I had read mention recently of > the ksh on osu-cis being the better one to use for the unix-pc, so I snarfed > it. (KSH+IN.Z) Not only did it execute the Cnews code properly, but it also > didn't give the ownership change of .kshistory. It may be preferable to get the osu-cis version of ksh, but for those die hards who persist with the stock ksh, here is what I've done; enter the following lines in your ksh environment file: function uid { typeset x y x=`id` y=${x%%'(*'} echo ${y#uid=} } typeset -xf uid trap ' [ `uid` = 0 ] && chown ${LOGNAME} ${HISTFILE:-${HOME}/.history} ' 0 It executes as you complete your 'su' session and changes ownership of the history file back to yourself. Jon -- Jon LaBadie {att, princeton, bcr, attmail!auxnj}!jonlab!jon
thad@public.BTR.COM (Thaddeus P. Floryan) (02/19/91)
jon@jonlab.UUCP (Jon H. LaBadie) in <921@jonlab.UUCP> writes, and many other
have followed up, regarding some tricks using the STORE's ksh for the 3B1.
Let me share some of my "tricks" for the "06/03/86" (KSH+IN.Z) version. And
note that the stuff in "THE KORN SHELL" book also documents the "06/03/86"
version but NOT the 1.2 or 1.9 versions accompanying the various fixdisks.
First, some extracts from my $HOME/.profile:
ENV=$HOME/.kshrc
PATH=/bin:/usr/bin:/usr/local/bin:/etc
SHELL=/bin/ksh
export ENV PATH SHELL
set -o ignoreeof
[...]
From my $HOME/.kshrc:
set -ao gmacs
ttyname=$(tty)
HISTFILE=$HOME/.kshist-${ttyname##*/};export HISTFILE
HISTSIZE=128;export HISTSIZE
MORE=-c
PATH=$PATH
PS1=`/usr/local/bin/kshpr`
PS2="ksh +> "
PS3=":> "
EDITOR=/usr/local/bin/emacs
FCEDIT=/usr/local/bin/emacs
VISUAL=/usr/local/bin/emacs
alias ll="ls -l"
The "set -o ignoreeof" is VERY important; prevents an itchy finger typing too
many ^D logging one off; with that option set, one must "exit" to logoff, and
the ^D still works fine for lower-level shell invocations ONLY when it is in
the .profile which is read only by the top-level ksh.
The "HISTFILE" was needed since I'm usually logged on serial port(s), ptys,
and at the console simultaneously; the "trick" creates uniquely-named files
based on the "line" over which one is logged in.
"root" on my systems also has "/bin/ksh" as its shell, and that works fine,
even "su'd" (nice, because if I type a command that requires root privs, I
just "su" then recall the original command).
That "kshpr" prompt program is so simple I've enclosed it at the end of this
posting.
Only two things have caused some grief using ksh, and the workaround is easy:
1) uucp requests using "~" need to be started from sh unless you really
want your home directory path substituted. What I usually do is have
my uucp requests in a file (for record-keeping purposes) then simply
do: sh file
A typical file (in my ~/uucp/work) looks like:
uucp -m osu-cis!~/GNU.how-to-get ~/osu-cis/
uucp -m osu-cis!~/ls-lR.Z ~/osu-cis/
echo "#\n#\t`date`\n#" >> files.osu-cis
echo "uucp -m osu-cis!~/GNU.how-to-get ~/osu-cis/" >> files.osu-cis
echo "uucp -m osu-cis!~/ls-lR.Z ~/osu-cis/" >> files.osu-cis
2) some items in crontab had to be qualified. For example (note /bin/sh):
#sccs "@(#)fndcmd:crontab 1.7"
#
#Mn Hr Da Mo Da (0=SUN, 1=MON, 2=TUE, 3=WED, 4=THU, 5=FRI, 6=SAT)
#of of of of of
#Hr Da Mo Yr Wk Command
#
16,46 * * * * /bin/su uucpadm -c "/usr/lib/uucp/uudemon.poll >/dev/null"
18,48 * * * * /bin/su uucpadm -c "/usr/lib/uucp/uudemon.hour >/dev/null"
00 4 * * * /bin/su uucpadm -c "/usr/lib/uucp/uudemon.admin >/dev/null"
59 23 * * * /bin/sh -c "/usr/local/bin/hdwarn.day >/dev/null"
59 23 * * * /bin/sh -c "/usr/local/bin/du-logs.day >/dev/null"
03 3 * * 0 /bin/sh -c "/etc/clockupd.wk >/dev/null"
30 5 * * 1 /bin/su uucpadm -c "/usr/lib/uucp/uudemon.cleanu >/dev/null"
30 5 * * 1 /bin/sh -c "/etc/cleanup.wk >/dev/null"
Thad Floryan [ thad@btr.com (OR) {decwrl, mips, fernwood}!btr!thad ]
-------------------- begin included material
---- Cut Here and feed the following to sh ----
#!/bin/sh
# This is a shell archive (produced by shar 3.49)
# To extract the files from this archive, save it to a file, remove
# everything above the "!/bin/sh" line above, and type "sh file_name".
#
# made 02/19/1991 09:56 UTC by thad@thadlabs
# Source directory /usr/local/src/kshpr
#
# existing files will NOT be overwritten unless -c is specified
#
# This shar contains:
# length mode name
# ------ ---------- ------------------------------------------
# 455 -rw-r--r-- Makefile
# 719 -rw-r--r-- kshpr.c
#
if touch 2>&1 | fgrep 'amc' > /dev/null
then TOUCH=touch
else TOUCH=true
fi
# ============= Makefile ==============
if test -f 'Makefile' -a X"$1" != X"-c"; then
echo 'x - skipping Makefile (File already exists)'
else
echo 'x - extracting Makefile (Text)'
sed 's/^X//' << 'SHAR_EOF' > 'Makefile' &&
X# System V (3B1) makefile for kshpr
X#
XCC = gcc
XCFLAGS = -O
XLDFLAGS = -s
XLIBS = /lib/crt0s.o /lib/shlib.ifile
XNAME = kshpr
XOBJS = kshpr.o
XSRCS = kshpr.c
XDEST = /usr/local/bin
XOWNER = thad
XGROUP = users
XFMODE = 555
X
X$(NAME) : $(OBJS)
X $(LD) $(LDFLAGS) -o $(NAME) $(OBJS) $(LIBS)
X
Xinstall : $(NAME)
X mv $(NAME) $(DEST)/
X chown $(OWNER) $(DEST)/$(NAME)
X chgrp $(GROUP) $(DEST)/$(NAME)
X chmod $(FMODE) $(DEST)/$(NAME)
X
Xclean :
X rm -f *~ $(OBJS) core
SHAR_EOF
$TOUCH -am 0930231490 'Makefile' &&
chmod 0644 Makefile ||
echo 'restore of Makefile failed'
Wc_c="`wc -c < 'Makefile'`"
test 455 -eq "$Wc_c" ||
echo 'Makefile: original size 455, current size' "$Wc_c"
fi
# ============= kshpr.c ==============
if test -f 'kshpr.c' -a X"$1" != X"-c"; then
echo 'x - skipping kshpr.c (File already exists)'
else
echo 'x - extracting kshpr.c (Text)'
sed 's/^X//' << 'SHAR_EOF' > 'kshpr.c' &&
X/* kshpr
X *
X * This program displays my idea of a ksh prompt that is different for a
X * normal user than it is for a su'd user.
X * returns a "false" status.
X *
X * The intent is for this program to be run in a .kshrc script per:
X *
X * PS1=`/usr/local/bin/kshpr`
X *
X * The normal output is: "nodename ksh $PPID/$$> ", and
X * the output if su'd is: "nodename ksh-su $PPID/$$# "
X *
X * Thad Floryan, 3-June-1989
X * Updated 30-Sep-90 to include nodename
X */
X
X#include <stdio.h>
X#include <sys/utsname.h>
X
Xextern int getuid(), uname();
X
Xmain()
X{
X struct utsname name;
X uname(&name);
X if (getuid() == 0)
X fprintf(stdout, "%s ksh-su $PPID/$$# ", name.nodename);
X else fprintf(stdout, "%s ksh $PPID/$$> ", name.nodename);
X}
SHAR_EOF
$TOUCH -am 0930232990 'kshpr.c' &&
chmod 0644 kshpr.c ||
echo 'restore of kshpr.c failed'
Wc_c="`wc -c < 'kshpr.c'`"
test 719 -eq "$Wc_c" ||
echo 'kshpr.c: original size 719, current size' "$Wc_c"
fi
exit 0