Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > gnu.bash.bug > #11324 > unrolled thread

Re: Feature Request re: syslog and bashhist

Back to article view | Back to gnu.bash.bug

This discussion starts older than the indexed window; earlier articles aren't shown. The article labeled Started by below is the oldest one visible, not the original post.

Contents

  Re: Feature Request re: syslog and bashhist aixtools <aixtools@gmail.com> - 2015-08-12 12:31 +0200
    Re: Feature Request re: syslog and bashhist arnold@skeeve.com (Aharon Robbins) - 2015-08-12 12:09 +0000
      Re: Feature Request re: syslog and bashhist Greg Wooledge <wooledg@eeg.ccf.org> - 2015-08-12 09:06 -0400
      Re: Feature Request re: syslog and bashhist Chet Ramey <chet.ramey@case.edu> - 2015-08-12 09:19 -0400
      Re: Feature Request re: syslog and bashhist aixtools <aixtools@gmail.com> - 2015-08-12 20:48 +0200

#11324 — Re: Feature Request re: syslog and bashhist

On 2015-08-10 10:19 PM, Chet Ramey wrote:
> On 8/9/15 1:37 PM, aixtools wrote:
>> Hi,
>>
>> Via google I came across the define named
>>
>> config-top.h:/* #define SYSLOG_HISTORY */
>>
>> Changing it (manually) to
>> config-top.h:#define SYSLOG_HISTORY
>>
>> Adds syslog statements such as:
>> Aug  9 16:52:55 x064 user:info syslog: HISTORY: PID=262242 UID=0 ls -ltr
>>
>> Request #1
>> Add a ./configure variable, e.g., --with-syslog_history
> I will think about this, but I am inclined not to do it.  It's easy enough
> to enable for those few user who want to do so.
Basically, I had not noticed it was there. It was only because I was at 
a customer who said they had customized their version years ago that I 
started searching for information about "bash and syslog".
Most of those hits were about using "fc" to add commands via the 
external syslogger - and these are the oldest, so the first, read top 
hits, that I got back. One of the replies mentioned the "top" include file.

This is actually, for me, the first compelling reason to switch shells 
for "what is provided" to what I must be certain is added.

In short, having it included in ./configure simply give it much more 
visibility - and perhaps adoption.
>> Request #2
>>
>> At the request of a bash user on AIX I made the following change to make
>> the syslog output "standardized" to AIX format for many applications so
>> that the output looks like this:
>>
>> Aug  9 17:30:12 x064 user:info syslog: bash[454682]: UID=0: ls -ltr
> The better way to do this is to use openlog().  I will add the necessary
> pieces to call openlog with the shell name as the identifier and LOG_PID
> as the default value for the log options.
I try to make minimal changes. There are perhaps many other 'things' to 
think about here. e.g., I thought about the syslog facility and level as 
a configureable, but have decided against - as someone could divert the 
log to an unmonitored facility - defeats the purpose.
However, maybe being able to specify what gets logged via a define 
(order of arguments, length, etc) might be "nice".

But, openlog() - I'll readup, but I expect that may be what "AIX" 
applications are using already to get "that" layout.

Many thanks for your consideration!
> Chet
>

[toc] | [next] | [standalone]

#11327

In article <mailman.8184.1439375524.904.bug-bash@gnu.org>,
aixtools  <aixtools@gmail.com> wrote:
>In short, having it included in ./configure simply give it much more 
>visibility - and perhaps adoption.

Personally, I think that having bash send executed commands to syslog
is an invasion of privacy; I'm surprised such a feature is even there
at all...

My two cents,

Arnold
-- 
Aharon (Arnold) Robbins 		arnold AT skeeve DOT com

[toc] | [prev] | [next] | [standalone]

#11328

On Wed, Aug 12, 2015 at 08:00:24AM -0500, John McKown wrote:
> Case 2: I'm running bash on my employer's system???. Do I really have an
> expectation of privacy on my employer's system? Why would I?

In some countries, yes, there is such an expectation.  Logging your
employees' activities may or may not be legal in any specific
jurisdiction.  Consult a lawyer for details.

[toc] | [prev] | [next] | [standalone]

#11331

On 8/12/15 8:09 AM, Aharon Robbins wrote:
> In article <mailman.8184.1439375524.904.bug-bash@gnu.org>,
> aixtools  <aixtools@gmail.com> wrote:
>> In short, having it included in ./configure simply give it much more 
>> visibility - and perhaps adoption.
> 
> Personally, I think that having bash send executed commands to syslog
> is an invasion of privacy; I'm surprised such a feature is even there
> at all...

And this is why it's not easy to turn on.  It's there for that small
set of system administrators who need it to satisfy some external
auditing requirement (in some cases legally required) -- that's why it's
available in the first place.

-- 
``The lyf so short, the craft so long to lerne.'' - Chaucer
		 ``Ars longa, vita brevis'' - Hippocrates
Chet Ramey, ITS, CWRU    chet@case.edu    http://cnswww.cns.cwru.edu/~chet/

[toc] | [prev] | [next] | [standalone]

#11332

On 2015-08-12 3:19 PM, Chet Ramey wrote:
> On 8/12/15 8:09 AM, Aharon Robbins wrote:
>> In article<mailman.8184.1439375524.904.bug-bash@gnu.org>,
>> aixtools<aixtools@gmail.com>  wrote:
>>> In short, having it included in ./configure simply give it much more
>>> visibility - and perhaps adoption.
>> Personally, I think that having bash send executed commands to syslog
>> is an invasion of privacy; I'm surprised such a feature is even there
>> at all...
> And this is why it's not easy to turn on.  It's there for that small
> set of system administrators who need it to satisfy some external
> auditing requirement (in some cases legally required) -- that's why it's
> available in the first place.
>
I guess my customer set all fall into this category.

And it is not fail safe - anyone willing, or able to use another shell 
can execute
a program such as vi, and then use a shell escape to start a different 
shell that is not logging.
Which is why auditing is used, which is involuntary from an application 
perspective.

So, referring back to John's addition, this would be useful for case #2.

Where it could be useful for case #3 - would be if bash had (or maybe 
has) an option to display
the configure arguments (which generally does not include -D flags), 
such as perl -V, or httpd -V.

Basically, if you have nothing to hide - it should not matter. More 
likely, it is a mechanism that
can prove your innocence should there ever be any doubt about what you 
did, or did not do.

Even in Germany - which has the reputation for most "protective" privacy 
laws. To meet PCI compliance
and others (I think even government in some sectors) - all commands are 
stored in order to perform an
audit in the case of a suspected security breach.

In any case, I understand that it is a sensitive topic - not one that I 
will be deciding.

I guess it might be worth a discussion to be able to see from a 
command-line option to know, one way or the other
if the feature is (potentially) active.

In short - Chet - as if I had a choice :p @ me - I bow to your wisdom!

[toc] | [prev] | [standalone]

Back to top | Article view | gnu.bash.bug

csiph-web