Re: Bug or missing feature in who

2007-05-25 Thread Andreas Schwab
[EMAIL PROTECTED] (Bob Proulx) writes:

 Alexander Schestag wrote:
 So, is there a way to tell who to list the users logged in via su
 as well?

 Not with who.  AFAIK you would need to walk the process list for that
 information.  There is really nothing special about a login process.
 It is just a normal process.

Actually a login process is kind of special, because it creates a new
session and becomes the leader of it.  Changing the user with su, on the
other hand, does not create a new session (use ps -ej to display the
session id of every process).  Still, it is the sole responsibility of
the process creating the session to update the utmp/wtmp information.
In other words, you cannot trust this information in any way.

Andreas.

-- 
Andreas Schwab, SuSE Labs, [EMAIL PROTECTED]
SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany
PGP key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
And now for something completely different.


___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils


Re: Bug or missing feature in who

2007-05-25 Thread Micah Cowan
Andreas Schwab wrote:
 [EMAIL PROTECTED] (Bob Proulx) writes:
 
 Alexander Schestag wrote:
 So, is there a way to tell who to list the users logged in via su
 as well?
 Not with who.  AFAIK you would need to walk the process list for that
 information.  There is really nothing special about a login process.
 It is just a normal process.
 
 Actually a login process is kind of special, because it creates a new
 session and becomes the leader of it.  Changing the user with su, on the
 other hand, does not create a new session (use ps -ej to display the
 session id of every process).  Still, it is the sole responsibility of
 the process creating the session to update the utmp/wtmp information.
 In other words, you cannot trust this information in any way.

Not to mention that it's trivially easy to create a new session, and
many programs do it as a matter of course (especially dæmons). The
create new session syscall is generally used to disassociate from
whatever terminal and process group it was running under, so it won't
accidentally try to write to the terminal while it's in the background
(STOPping it); and won't receive SIGHUP if that terminal goes away.

-- 
Micah J. Cowan
Programmer, musician, typesetting enthusiast, gamer...
http://micah.cowan.name/


___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils


Bug or missing feature in who

2007-05-24 Thread Alexander Schestag
Hello,

I think, I detected a bug or at least a missing feature in the who
command. Assume the following situation:

- user1 is logged in. a who will show me this user.
- after that, user1 logs in as another user or as root via su.

Unfortunately, in this situation, the who command doesn't list the
user logged in via su. Is this a bug, a missing feature, or is it a
wanted behaviour of who? who /var/log/wtmp/ lists the logged in root
user, but it also lists users already logged out. So, is there a way to
tell who to list the users logged in via su as well?

Best wishes,

Alex Schestag

-- 
Alexander Schestag
http://www.schestag.info
PGP encryption welcome! Key-ID: 0x1F938C08 @ usual places


___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils


Re: Bug or missing feature in who

2007-05-24 Thread Bob Proulx
Alexander Schestag wrote:
 I think, I detected a bug or at least a missing feature in the who
 command.

The who command reports information found in the system utmp file.
But updating the contents of the utmp file is the responsibility of
the operating system.

 Assume the following situation:
 
 - user1 is logged in. a who will show me this user.

The /bin/login program, and any replacement such as sshd or the
older telnetd, update the contents of the /var/run/utmp file when a
user logs into the session.

 - after that, user1 logs in as another user or as root via su.

The su command does not update the utmp file.  Running su does not
change the name of the user who logged into that session.

 Unfortunately, in this situation, the who command doesn't list the
 user logged in via su. Is this a bug, a missing feature, or is it a
 wanted behaviour of who?

It is not a bug.  It is expected behavior.  The 'su' command stacks
another process on top of the first with the new process being the new
user.  But this does not change who logged into that session.  The
first user logged into that terminal session and therefore the system
utmp file will continue to show the previous user on that session.
When you exit the stacked shell you will return to the previous user
session.

The utmp file is a very old part of unix-like systems.  I doubt if
today, 30 years later, that it would be implemented the way that it
was way back then.  Note that the utmp and wtmp files are running
totals kept by various system programs.  It is not unusual for system
events (e.g. disk full, crashed login shells) to cause them to be out
of sync with each other.  I would not use it for ultimate accuracy.

There is very little good use of the utmp file today.  Most people
using it should probably be using the user name of the current user
and not the user that logged into that terminal session.

 who /var/log/wtmp/ lists the logged in root user,

The wtmp file attempts to track logins and logouts.  The utmp file
attempts to track currently logged in users.

 but it also lists users already logged out.

Correct.

 So, is there a way to tell who to list the users logged in via su
 as well?

Not with who.  AFAIK you would need to walk the process list for that
information.  There is really nothing special about a login process.
It is just a normal process.

If I read what you said right it sounds like you are logging in as
root and then using su to switch to a user.  In which case the logged
in user is root and the report is correct.

Bob


___
Bug-coreutils mailing list
Bug-coreutils@gnu.org
http://lists.gnu.org/mailman/listinfo/bug-coreutils