su unterschlägt Meldungen??

[MIKQ]

su unterschlägt Meldungen?? [GELÖST]

Hi,

habe folgendes Problem.
Möchte mich nicht als root einloggen, sondern höchstens per su root zu root werden.
Das klappt auch ganz gut allerdings erhalte ich dann als dieser "su-root" keinerlei Meldungen!
Nicht nur Warnings wie "Accepted password for root from 192.168.X.X port 1721 ssh2"

oder
"Jan 28 23:04:11 Name su: User to root on /dev/ttyp4"

sondern auch sehr wichtige Meldungen werden verschluckt!

Z.B. der Befehl # kill -HUP `cat /var/run/sshd.pid` funktioniert einwandfrei, nur was er gemacht hat hat er bisher als :

"Received SIGHUP; restarting.
Jan 28 23:00:20 Name sshd[20164]: Server listening on :: port XXXX.
Jan 28 23:00:20 Name sshd[20164]: Server listening on 0.0.0.0 port XXXXX"

ausgegeben.

Als su-root nichts mehr.
Einfach nur das Prompt kommt zurück.
Habe su mit su -l und su -u ausprobiert alles mit dem gleichen bescheidenem Ergebnis.



Pls Help!

Danke

 

[current]

Hast du schon deine syslog.conf gecheckt? Läuft dein syslogd?

 

[MIKQ]

syslogd läuft:

Memory: Real: 6172K/19M act/tot  Free: 39M  Swap: 0K/110M used/tot

  PID USERNAME PRI NICE  SIZE   RES STATE WAIT     TIME    CPU COMMAND
15164 root       2    0  712K  840K sleep select  22:54  0.98% ppp
22499 root       2    0  172K  416K sleep select   3:40  0.34% pppoe
 5971 root       2    0  776K  864K sleep select   0:06  0.00% sendmail
11783 root       4    0  396K  276K sleep bpf      0:02  0.00% pflogd
28224 _syslogd   2    0  180K  352K sleep select   0:00  0.00% syslogd
13472 root       2    0  248K  236K sleep select   0:00  0.00% cron
 7377 nobody     2    0  160K  364K idle  select   0:00  0.00% dnsmasq
15169 root       2    0  416K 1388K idle  netio    0:00  0.00% sshd
24045 root       2    0  140K  136K sleep netio    0:00  0.00% syslogd
 5844 Frank      2    0  380K 1168K sleep select   0:00  0.00% sshd
 8972 root      10    0  824K  776K sleep wait     0:00  0.00% bash
25468 root       2    0  324K  232K idle  select   0: 00  0.00% sshd
    1 root      10    0  340K  100K idle  wait     0:00  0.00% init
14921 Frank     10    0  848K  752K sleep wait     0:00  0.00% bash
 4161 root      28    0  184K  856K run   -        0:00  0.00% top
  175 root       3    0   96K    4K idle  ttyin    0:00  0.00% getty
   91 root       3    0   64K    4K idle  ttyin    0:00  0.00% getty
 1774 root       3    0  108K    4K idle  ttyin    0:00  0.00% getty
 6905 root       3    0   64K    4K idle  ttyin    0:00  0.00% getty
 8866 root       3    0   96K    4K idle  ttyin    0:00  0.00% getty
  275 root      18    0  128K    4K idle  pause    0:00  0.00% inetd

Was soll/soll denn nicht in der syslog.conf drin stehen?
Für mich sieht alles i.Ordnung aus:

    I    syslog.conf                                                                                                               Row 1    Col 1    5:18  Ctrl-K H for help
#       $OpenBSD: syslog.conf,v 1.13 2003/06/26 18:24:25 jmc Exp $
#

*.err;kern.debug;auth.notice;authpriv.none;mail.crit    /dev/console
*.notice;auth,authpriv,cron,ftp,kern,lpr,mail,user.none /var/log/messages
kern.debug;user.info;syslog.info                        /var/log/messages
auth.info                                               /var/log/authlog
authpriv.debug                                          /var/log/secure
cron.info                                               /var/cron/log
daemon.info                                             /var/log/daemon
ftp.info                                                /var/log/xferlog
lpr.debug                                               /var/log/lpd-errs
mail.info                                               /var/log/maillog
#uucp.info                                              /var/log/uucp

*.err                                                   root
*.notice;auth.debug                                     root
*.alert                                                 root
*.emerg                                                 *

# Uncomment to log to a central host named "loghost".   You need to run
# syslogd with the -u option on the remote host if you are using this.
# (This is also required to log info from things like routers and
# ISDN-equipment).  If you run -u, you are vulnerable to syslog bombing,
# and should consider blocking external syslog packets
#*.notice;auth,authpriv,cron,ftp,kern,lpr,mail,user.none        @loghost
#kern.debug,user.info,syslog.info                               @loghost
#auth.info,authpriv.debug,daemon.info                           @loghost

#eingefuegt nov 04 fuer kiwi syslogd on xp maschine
#*.notice;auth,authpriv,cron,ftp,kern,lpr,mail,user.none        @qwxp
#kern.debug,user.info,syslog.info                               @qwxp
#auth.info,authpriv.debug,daemon.info                           @qwxp


# Uncomment to log messages from sudo(8) and chat(8) to their own
# respective log files.  Matches are done based on the program name
# Program-specific logs:
#!sudo
#*.*                                                    /var/log/sudo
#!chat
#*.*                                                    /var/log/chat

Gruß MIKQ

 

[MIKQ]

JETZT weis ich was Du meinst.
Bin zufällig auf folgendes Posting gestossen:
Messages für Root an und abschalten

Ich habe den User von dem aus ich su mache nun neben root in der syslog.conf eingtragen.
A la

*.notice;auth.debug                                     root,User

Dennoch halte ich es für ein Fehler von su die Nachrichten die an root gehen nicht durchzuschleifen.
Ist das gewolltes Verhalten?


Gruß

 

[current]

Dennoch halte ich es für ein Fehler von su die Nachrichten die an root gehen nicht durchzuschleifen.
Ist das gewolltes Verhalten?

Ein bischen Spekulation meinerseits, da ich mich an der Stelle nicht 100%-ig auskenne: um eine Meldung an den User 'user' zu schicken, schaut der syslogd in der utmp nach um herauszufinden, an welchen ttys ein Benutzer eingeloggt ist und schreibt die Meldung auf das entsprechende tty.

Wenn du dich per ssh einloggst, gehört das tty eben dem Benutzer, mit dem du ankommst. Ein su - root o.ä. ändert den Owner des tty nämlich nicht mehr. Mit dieser Argumentation würde ich von einem gewollten Verhalten ausgehen.