Regression: only session timeout and nologin are checked for timeoutd

Bug #560925 reported by Valdisvi
20
This bug affects 3 people
Affects Status Importance Assigned to Milestone
timeoutd (Ubuntu)
In Progress
Undecided
Unassigned

Bug Description

Binary package hint: timeoutd
Was tested on 10.04 (Lycid Lynx) Beta2.

This probably appeared after bugs https://bugs.launchpad.net/bugs/121960 and https://bugs.launchpad.net/bugs/137250 was fixed. Before that time checking was OK.

To check this try these lines for e.g. for user "user", use configuration in /etc/timeouts:
Al0800-0900:*:user:*:NOLOGIN
Al:*:user:*:0:2:0:1

Log in as user, and run command:
watch -d 'timeoutd tv tty1; echo $?'

After 1 minute will get warning about logging off.

Though if overall day limit is set, e.g.
Al:*:user:*:0:0:2:1

Then status is always 0, and user is never logged off. So, my kids simply log in again, when they are logged off, if time is outside nologin range of time.

Tags: patch
summary: - Regression only session timeout and nologin are checked
+ Regression only session timeout and nologin are checked for timeoutd
summary: - Regression only session timeout and nologin are checked for timeoutd
+ Regression: only session timeout and nologin are checked for timeoutd
description: updated
description: updated
description: updated
description: updated
Revision history for this message
Valdisvi (valdis-vitolins) wrote :

When timeoutd.c (got from Ubuntu source repository) compiled with DEBUG flag, /var/log/debug shows:
...
Apr 11 23:59:46 piano timeoutd[25824]: Reading today's wtmp entries.
Apr 11 23:59:46 piano timeoutd[25824]: Seek to end of wtmp
Apr 11 23:59:46 piano timeoutd[25824]: Finished reading today's wtmp entries.
Apr 11 23:59:46 piano timeoutd[25824]: Time to check utmp for exceeded limits.
Apr 11 23:59:46 piano timeoutd[25824]: User ieva or * not in config -> No restrictions. Not checking ieva on pts/2
Apr 11 23:59:46 piano timeoutd[25824]: User valdis or * not in config -> No restrictions. Not checking valdis on pts/2
Apr 11 23:59:46 piano timeoutd[25824]: NO xsession detected. device=pts/2 host=inks.lan
Apr 11 23:59:46 piano timeoutd[25824]: Checking user tv group users tty pts/2.
Apr 11 23:59:46 piano timeoutd[25824]: Matched entry 5
Apr 11 23:59:46 piano timeoutd[25824]: Idle=0 (max=0) Sess=3 (max=120) Daily=0 (max=120) warntime=1
Apr 11 23:59:46 piano timeoutd[25824]: NO xsession detected. device=pts/2 host=inks.lan
Apr 11 23:59:46 piano timeoutd[25824]: TTY pts/2: Discipline=TTY.
Apr 11 23:59:46 piano timeoutd[25824]: User tv is active.
Apr 11 23:59:46 piano timeoutd[25824]: Freeing list of today's wtmp entries.
Apr 11 23:59:46 piano timeoutd[25824]: Finished freeing list of today's wtmp entries.
Apr 11 23:59:46 piano timeoutd[25824]: Finished checking utmp... sleeping for 1 minute.
...
Note, that Daily=0 all the time. Though couldn't catch how it is counted and where the bug is.

Revision history for this message
Valdisvi (valdis-vitolins) wrote :

What I found analyzing and testing timeoutd.c code from Ubuntu source repository is that,
when get_day_time(user) function is invoked, it doesn't follow into
while (login_p) and eventually while (logout_p) branches, so daytime variable is always 0.

Revision history for this message
Atanas (atanasd) wrote :

It didn't follow into the while (login_p) because read_wtmp() returned garbage.
It was attempting to read an always 32-bit value (ut.ut_time, actually ut.ut_tv.tv_sec) with an arch dependent (time_t *) pointer, which on 64-bit systems expects 64-bits of data. So half of the bits were some random junk and read_wtmp() was just skipping all past login session records.

The following patch appears to fix that:

--- timeoutd.c-old 2012-05-10 16:00:21.000000000 +0200
+++ timeoutd.c 2012-05-11 14:38:35.514021308 +0200
@@ -418,7 +418,8 @@
.
     while (fread(&ut, sizeof(struct utmp), 1, fp) == 1)
     {
- tm = localtime(&ut.ut_time);
+ time_t utmp_time = ut.ut_time;
+ tm = localtime(&utmp_time);
.
       if (tm->tm_year != now.tm_year || tm->tm_yday != now.tm_yday)
         break;

Revision history for this message
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in timeoutd (Ubuntu):
status: New → Confirmed
Revision history for this message
Risto Mononen (risto-mononen-deactivatedaccount) wrote :

wtmplist is always null when entering get_day_time(), line 777, when debugging with gdb. The daytime calculation does not work at all.

776 daytime = 0;
777 login_p = wtmplist;
778 while (login_p)

Revision history for this message
Risto Mononen (risto-mononen-deactivatedaccount) wrote :

The localtime - utmp_time comparison did not work. I will post a fix soon.

Revision history for this message
Risto Mononen (risto-mononen-deactivatedaccount) wrote :

Time comparison is now done with seconds rather than localtime (strings). At least max session and daily rule test cases worked ok. The code is in
https://github.com/risto-mononen/timeoutd.git

Sorry I don't know how to provide patches or bazaar branches (yet).

Revision history for this message
Risto Mononen (risto-mononen-deactivatedaccount) wrote :

make clean
make
sudo make install

Changed in timeoutd (Ubuntu):
status: Confirmed → In Progress
assignee: nobody → Risto Mononen (risto-mononen)
Revision history for this message
Ubuntu Foundations Team Bug Bot (crichton) wrote :

The attachment "Fix timeoutd.c and Makefile" of this bug report has been identified as being a patch. The ubuntu-reviewers team has been subscribed to the bug report so that they can review the patch. In the event that this is in fact not a patch you can resolve this situation by removing the tag 'patch' from the bug report and editing the attachment so that it is not flagged as a patch. Additionally, if you are member of the ubuntu-reviewers team please also unsubscribe the team from this bug report.

[This is an automated message performed by a Launchpad user owned by Brian Murray. Please contact him regarding any issues with the action taken in this bug report.]

tags: added: patch
Revision history for this message
Risto Mononen (risto-mononen-deactivatedaccount) wrote :
Revision history for this message
Risto Mononen (risto-mononen-deactivatedaccount) wrote :
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.