User session opened and closed msg in /var/log/messages

andiramesh · 08-01-2008, 03:08 PM

Hi,
Due to one of our application, the following messages are logging frequently in var/log/messages in my linux server.I want to discard this particulat msg logging in /var/log/messages.Is it possible?
May 15 18:10:22 betaotuc su(pam_unix)[21589]: session closed for user htuser
May 15 18:11:16 betaotuc su(pam_unix)[22573]: session opened for user htuser by (uid=0)
May 15 18:11:22 betaotuc su(pam_unix)[22573]: session closed for user htuser
May 15 18:12:16 betaotuc su(pam_unix)[23574]: session opened for user htuser by (uid=0)
May 15 18:12:21 betaotuc su(pam_unix)[23574]: session closed for user htuser
May 15 18:13:16 betaotuc su(pam_unix)[24561]: session opened for user htuser by (uid=0)
May 15 18:13:22 betaotuc su(pam_unix)[24561]: session closed for user htuser
May 15 18:14:16 betaotuc su(pam_unix)[25554]: session opened for user htuser by (uid=0)

Please help me to disable this error mesg logging.

taxtropel · 08-01-2008, 07:32 PM

it looks like you are letting the web server user run the application as root. this is a serious security problem and you should probably look at setting the application up differently rather than trying to omit the log entry.

Mr. C. · 08-01-2008, 07:38 PM

Show your /etc/syslog.conf file please.

This logging is controlled there.

andiramesh · 08-04-2008, 01:09 AM

Thanksfor helping me.Please see the syslog.conf file below,

# Log all kernel messages to the console.
# Logging much else clutters up the screen.
#kern.* /dev/console

# Log anything (except mail) of level info or higher.
# Don't log private authentication messages!
*.info;mail.none;cron.none;authpriv.none /var/log/messages

# The authpriv file has restricted access.
authpriv.* /var/log/secure

# Log all the mail messages in one place.
mail.* -/var/log/maillog

# Log cron stuff
cron.* /var/log/cron

# Everybody gets emergency messages
*.emerg *

# Save news errors of level crit and higher in a special file.
uucp,news.crit /var/log/spooler

# Save boot messages also to boot.log
local7.* /var/log/boot.log

Mr. C. · 08-04-2008, 02:28 AM

The pam messages you are interested in should be logged at authpriv.info, and your syslog.conf file indicates that those messages should *not* be output to /var/log/messages. And yet they appear. It may be that the messages are logged at auth.info instead on your system, so change the following lines in syslog (changed marked in bold)):

Code:

# Log anything (except mail) of level info or higher.
# Don't log private authentication messages!
*.info;mail.none;cron.none;authpriv.none /var/log/messages

# The authpriv file has restricted access.
authpriv.* /var/log/secure

to

Code:

# Log anything (except mail) of level info or higher.
# Don't log private authentication messages!
*.info;mail.none;cron.none;authpriv.none;auth.none /var/log/messages

# The authpriv file has restricted access.
auth.*;authpriv.* /var/log/secure

and restart syslog as root (use sudo or whatever method you use to be root):

/etc/init.d/sysklogd restart

Your syslog startup script may have a different name, so look in /etc/init.d/ for scripts that are similarly named.

Then, try your su test again and see if the pam_unix messages appear in one of the /var/log/auth* logs, and not /var/log/messages.

andiramesh · 08-05-2008, 08:32 AM

Thank You Mr.C. Your suggestion worked for me.Thanks a lot for your help.
Now the session opened and closed messages are logging in /var/log/secure which is not disturbing us.

Mr. C. · 08-05-2008, 11:25 AM

Great, thanks for posting that the solution worked so others can resolve the issue too.

idallen · 09-04-2008, 10:03 PM

Quote:

Originally Posted by Mr. C.

It may be that the messages are logged at auth.info instead on your system

You can find out exactly what level and priority are being logged
to syslog by adding a line similar to this to syslog.conf and
restarting/reloading syslog:

Code:

*.* @1.2.3.4

where IP address 1.2.3.4 is either some machine on your local network
such as your gateway/router (best) or some machine on a distant network.

This will redirect everything coming into syslog to that IP address, so
you can then use tcpdump (as root) to look at it as it leaves. (You don't
care if it arrives; you only want to see it leave.) I forwarded syslog
traffic back to my gateway router at 192.168.9.254 and dumped it:

Code:

*.* @192.168.9.254

Code:

# tcpdump -n -v -s 1500 -i eth0 host 192.168.9.254 and port 514
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 1500 bytes
22:55:50.325483 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 90) 192.168.9.250.514 > 192.168.9.254.514: SYSLOG, length: 62
	Facility kernel (0), Severity info (6)
	Msg: kernel: [14957.892858] device eth0 entered promiscuous mode
22:55:50.325532 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 124) 192.168.9.250.514 > 192.168.9.254.514: SYSLOG, length: 96
	Facility kernel (0), Severity notice (5)
	Msg: kernel: [14957.892870] audit(1220583350.324:23): dev=eth0 prom=256 old_prom=0 auid=4294967295
22:56:01.769846 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 110) 192.168.9.250.514 > 192.168.9.254.514: SYSLOG, length: 82
	Facility authpriv (10), Severity info (6)
	Msg: CRON[3346]: pam_unix(cron:session): session opened for user idallen by (uid=0)
22:56:01.769918 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto UDP (17), length 111) 192.168.9.250.514 > 192.168.9.254.514: SYSLOG, length: 83
	Facility cron (9), Severity info (6)
	Msg: /USR/SBIN/CRON[3347]: (idallen) CMD (cd logs && $HOME/sh/doexpectspeedstats.sh)
...etc...

From the above, I can see that I need to ignore both authpriv.info and
cron.info to cut down on the CRON noise.

Mr. C. · 09-04-2008, 10:41 PM

Or you can either attach a debugger to the running process, placing a breakpoint at syslog, and examine the arguments passed, or connect to it with strace -p PID and watch for syslog calls. Either of these is trivial to do.

andiramesh · 09-05-2008, 05:47 AM

Thank you so much Mr.C.The information is very useful for us