From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 949 invoked from network); 10 Jul 2007 01:28:09 -0000 X-Spam-Checker-Version: SpamAssassin 3.2.1 (2007-05-02) on f.primenet.com.au X-Spam-Level: X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,HTML_MESSAGE autolearn=ham version=3.2.1 Received: from news.dotsrc.org (HELO a.mx.sunsite.dk) (130.225.247.88) by ns1.primenet.com.au with SMTP; 10 Jul 2007 01:28:09 -0000 Received-SPF: none (ns1.primenet.com.au: domain at sunsite.dk does not designate permitted sender hosts) Received: (qmail 16479 invoked from network); 10 Jul 2007 01:28:03 -0000 Received: from sunsite.dk (130.225.247.90) by a.mx.sunsite.dk with SMTP; 10 Jul 2007 01:28:03 -0000 Received: (qmail 16638 invoked by alias); 10 Jul 2007 01:28:00 -0000 Mailing-List: contact zsh-workers-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 23669 Received: (qmail 16628 invoked from network); 10 Jul 2007 01:27:59 -0000 Received: from news.dotsrc.org (HELO a.mx.sunsite.dk) (130.225.247.88) by sunsite.dk with SMTP; 10 Jul 2007 01:27:59 -0000 Received: (qmail 16114 invoked from network); 10 Jul 2007 01:27:59 -0000 Received: from wx-out-0506.google.com (66.249.82.234) by a.mx.sunsite.dk with SMTP; 10 Jul 2007 01:27:55 -0000 Received: by wx-out-0506.google.com with SMTP id h27so1104417wxd for ; Mon, 09 Jul 2007 18:27:55 -0700 (PDT) DKIM-Signature: a=rsa-sha1; c=relaxed/relaxed; d=gmail.com; s=beta; h=domainkey-signature:received:received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=XTl8llwsuvPA8HI0DnMlQhvSVa30Bq/9OHk2mGUMvHv4zssDy8A+zGnnIVogPRrkiWd7z6hUv4WDDqvMOql+nfmZUIBAzHYTkGuUnX/LrNC/MontHLiTYvnI3Ef0WGpLsNezD1b+ZxGcjkwjHvW5aDmM+8mgs0DFOmOasOF0y7o= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=beta; h=received:message-id:date:from:to:subject:cc:in-reply-to:mime-version:content-type:references; b=PMHau8+rfbUMjveT4PFco8eY6yHrPEu61wBR6jR9L/2t6kOJl2udV2Ox7xq9Ly+RnE+piOxFjx/gw2+ix9JRPXC8R67agaYpPgClvssrwLoI+tyV0rQ2bYjnlh1CwHwlX7kfX/ziCGwlvP7s5vPZvQncVOYnqj3ottrBmhhPi/w= Received: by 10.70.21.8 with SMTP id 8mr6814449wxu.1184030874937; Mon, 09 Jul 2007 18:27:54 -0700 (PDT) Received: by 10.70.117.18 with HTTP; Mon, 9 Jul 2007 18:27:54 -0700 (PDT) Message-ID: <3cb6e920707091827m41d85d0dwa33f3d2cebb7b8e2@mail.gmail.com> Date: Mon, 9 Jul 2007 21:27:54 -0400 From: "Joe D" To: "Bart Schaefer" Subject: Re: adding history logging "automagically" :) Cc: zsh-workers@sunsite.dk In-Reply-To: <070709174750.ZM11342@torch.brasslantern.com> MIME-Version: 1.0 Content-Type: multipart/alternative; boundary="----=_Part_105789_12790096.1184030874680" References: <3cb6e920707091041t3b3f5c1cy7d7b08e6028c22f9@mail.gmail.com> <070709174750.ZM11342@torch.brasslantern.com> ------=_Part_105789_12790096.1184030874680 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline On 7/9/07, Bart Schaefer wrote: > > On Jul 9, 1:41pm, Joe D wrote: > } > } So in a nutshell, all I want to do is modify 'zsh' source > > Ick. Don't do that. If there's a way to 'hide' it from the regular users (sure, those more ambitious will figure it out, but not worried about them), then i'd do it. > > I don't think you want SHARE_HISTORY - that means the shells pass the > current history around among themselves while they are running. You > don't really want Alice to see Bob's commands, do you? Good point. Also I think APPEND_HISTORY is redundant with INC_APPEND_HISTORY, but > it probably won't hurt anything. Okay. In any case you're going to be defeated here by a zsh security feature > that prevents the shell from using a history file that is owned and/or > writable by someone else. Each shell will try to assume ownership of > the file and remove group/other write permission, so there will be a > mad scramble of unlinking/recreating of the file as each shell notices > that one of the others has tried to grab it. That's probably why you > can't find the file even though you can find the lock. Ah, ok... The best you might be able to do is > > HISTFILE=/opt/some_location/.$USER.log > > so that every user has his or her own history file in some_location. > > Beyond that, I suggest placing > > if [[ $USER = (list|of|problem|users) ]]; then > readonly HISTSIZE=1000 > readonly SAVEHIST=1000 > readonly HISTFILE=/opt/some_location/.$USER.log > setopt APPEND_HISTORY > setopt INC_APPEND_HISTORY > setopt EXTENDED_HISTORY > fi > > in /etc/zshenv, which is always run (unless the shell was configured > with --disable-zshenv). Using EXTENDED_HISTORY will give you time > stamps on the entries, so you can combine and sort the users' log > files to determine the order of events. > > They could still deliberately mess you up by frobbing those setopts > later ... so I suppose if you must hack the source, the place to put > your dosetopt() calls would be in Src/init.c, in loop(), with an > "if (toplevel)" test protecting them. But if your users are so badly > behaved as to ignore your instructions to leave those options alone, > you have worse problems than just tracking down what happened when. > Good suggestions - thanks Bart. I'll give the /etc/zshenv options a try and see if that is enough to handle our problem users. Thanks, Joe. ------=_Part_105789_12790096.1184030874680 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline

On 7/9/07, Bart Schaefer <schaefer@brasslantern.com> wrote:
On Jul 9,  1:41pm, Joe D wrote:
}
} So in a nutshell, all I want to do is modify 'zsh' source

Ick.  Don't do that.


If there's a way to 'hide' it from the regular users (sure, those more ambitious will figure it out, but not worried about them), then i'd do it.
 

I don't think you want SHARE_HISTORY - that means the shells pass the
current history around among themselves while they are running.  You
don't really want Alice to see Bob's commands, do you?


Good point.
 

Also I think APPEND_HISTORY is redundant with INC_APPEND_HISTORY, but
it probably won't hurt anything.


Okay.

 

In any case you're going to be defeated here by a zsh security feature
that prevents the shell from using a history file that is owned and/or
writable by someone else.  Each shell will try to assume ownership of
the file and remove group/other write permission, so there will be a
mad scramble of unlinking/recreating of the file as each shell notices
that one of the others has tried to grab it.  That's probably why you
can't find the file even though you can find the lock.


Ah, ok...
 

The best you might be able to do is

HISTFILE=/opt/some_location/.$USER.log

so that every user has his or her own history file in some_location.

Beyond that, I suggest placing

if [[ $USER = (list|of|problem|users) ]]; then
  readonly HISTSIZE=1000
  readonly SAVEHIST=1000
  readonly HISTFILE=/opt/some_location/.$USER.log
  setopt APPEND_HISTORY
  setopt INC_APPEND_HISTORY
  setopt EXTENDED_HISTORY
fi

in /etc/zshenv, which is always run (unless the shell was configured
with --disable-zshenv).  Using EXTENDED_HISTORY will give you time
stamps on the entries, so you can combine and sort the users' log
files to determine the order of events.

They could still deliberately mess you up by frobbing those setopts
later ... so I suppose if you must hack the source, the place to put
your dosetopt() calls would be in Src/init.c, in loop(), with an
"if (toplevel)" test protecting them.  But if your users are so badly
behaved as to ignore your instructions to leave those options alone,
you have worse problems than just tracking down what happened when.


Good suggestions - thanks Bart.  I'll give the /etc/zshenv options a try and see if that is enough to handle our problem users. 

Thanks,
Joe.
------=_Part_105789_12790096.1184030874680--