| 1 |
On 11/16/20 4:22 PM, Jack wrote: |
| 2 |
> On 2020.11.15 19:02, Jack wrote: |
| 3 |
>> As usual, I've got what seems to be a really obscure problem, and I |
| 4 |
>> have not found any reference to it searching the interwebs. |
| 5 |
>> |
| 6 |
>> The suspect package is sys-auth/rtkit-0/13-r1 (which has nothing to do |
| 7 |
>> with chkrootkit) and I'm using app-admin/syslog-ng-3.26.1-r1. |
| 8 |
>> |
| 9 |
>> As a typical example from /var/log/messages (extract, and having |
| 10 |
>> reconfigured syslog-ng to us iso timestamps) |
| 11 |
>> |
| 12 |
>> 2020-11-15T18:30:01-05:00 localhost CROND[7320]: (root) CMD |
| 13 |
>> (/usr/lib/sa/sa1 1 1) |
| 14 |
>> 2020-11-15T23:34:10-05:00 localhost rtkit-daemon[6263]: Supervising 0 |
| 15 |
>> threads of 0 processes of 0 users. |
| 16 |
>> 2020-11-15T23:36:38-05:00 localhost rtkit-daemon[6263]: Supervising 0 |
| 17 |
>> threads of 0 processes of 0 users. |
| 18 |
>> 2020-11-15T18:40:01-05:00 localhost CROND[15943]: (root) CMD (test -x |
| 19 |
>> /usr/sbin/run-crons && /usr/sbin/run-crons) |
| 20 |
>> |
| 21 |
>> All rtkit messages to syslog seem to be in UTC, or at least five hours |
| 22 |
>> off from my local Americas/New York timezone. rtkit uses the syslog() |
| 23 |
>> call for all logging, and there is nothing in those calls that even |
| 24 |
>> mentions timezone. |
| 25 |
>> |
| 26 |
>> However, in digging further, I found two log entries from rtkit which |
| 27 |
>> do appear to be using local time. In looking at the rtkit source, |
| 28 |
>> those two use the LOG_INFO and LOG_NOTICE as their levels. All other |
| 29 |
>> logging in rtkit uses LOG_ERR, LOG_DEBUG, or LOG_WARNING, with one |
| 30 |
>> exception: I see one LOG_INFO message (repeated, scattered across the |
| 31 |
>> log) which does show the UTC time. |
| 32 |
>> |
| 33 |
>> So, does anyone have an idea what is going on? |
| 34 |
>> |
| 35 |
>> I have one theory so far, but I a bit stuck on how to test it. I'm |
| 36 |
>> not sure where in the boot process rtkit gets started, but I think |
| 37 |
>> it's automatically started when Dbus starts. As part of the daemon's |
| 38 |
>> startup routine, it drops some privileges. Is it possible that the |
| 39 |
>> applicable timezone gets changed when it drops privileges? As far as |
| 40 |
>> I can tell, the log messages with the correct time are all produced |
| 41 |
>> before it drops privs. Am I barking up the right tree, or am I |
| 42 |
>> barking mad? |
| 43 |
> |
| 44 |
> I've done some more digging, with lots of debugging output. Up to a |
| 45 |
> point, the process acknowledges the local timezone. However, after |
| 46 |
> doing a 'chroot "/proc"' and then 'chdir "/"' it thinks it's UTC. Still |
| 47 |
> doesn't make any sense to me, though. |
| 48 |
|
| 49 |
glibc uses /etc/localtime to for timezone conversion. Changing root to |
| 50 |
a new root directory that does not have this file (or has a different |
| 51 |
one in its place) will show a different local time conversion. |
| 52 |
|
| 53 |
Example program: |
| 54 |
#include <stdio.h> |
| 55 |
#include <time.h> |
| 56 |
#include <unistd.h> |
| 57 |
|
| 58 |
int main() |
| 59 |
{ |
| 60 |
time_t now = time(NULL); |
| 61 |
printf("Time outside of chroot = %s", ctime(&now)); |
| 62 |
chroot("/proc"); |
| 63 |
printf("Time inside of chroot = %s", ctime(&now)); |
| 64 |
return 0; |
| 65 |
} |
| 66 |
|
| 67 |
Time outside of chroot = Mon Nov 16 17:58:19 2020 |
| 68 |
Time inside of chroot = Tue Nov 17 01:58:19 2020 |
| 69 |
|
| 70 |
Cal |
Archives