First things first: I am convinced now that there is no problem with the
reboot session id. I probably should have sone some quick math in the
first place.
But still some comments...
> > think about a tool like logger. As of my understanding, each
> > command-line invocation would create a new "reboot session".
>
>
> Rainer, I think your example isn't typical.
I agree. But it is a real one ;)
>
> On most system, there is one "global" sender (syslogd on unix), which
> run's very long. Usually as long the system is up. It has the counter.
> This sender get's it data from several sourcer (Applications using
> "syslog() call in libC; again a unix example). So "booting" an
> application, --read: you command line tool-- has no effect on the
> reboot counter.
Agreed - but we do not life in an *nix only world. I am not sure if
homogenious systems would be better accepted if the only OS would be
*nix, but as of now we do have some others out. Look, we (mainly, I can
say nowadays;)) implement on Windows. There is no such central sender.
We need to "boot" each application...
>
> See below, for details of your example...
> But first, on "the central syslogd"; the RFC doesn't demand it, but
> assumes the is only 1 sender on each system. E.g. the "private key" is
> shared by all signatures, so by all "sources". Hard to do when all
> applications are senders itself.
If that is the case, we indeed have an issue here. Not a big issue if a
single vendor's products run on the non-*nix box. But what if e.g.
Adiscon's EventReporter runs on the same system Kiwi's syslogd runs... I
think there are ways to work this out, but I also think -sign can be
implemented to work around this. I think we do not absolutely have only
one private key for the system.
I am NOT arguing to change anything in -sign (at least yet). I am just
picking up the thought...
>
> Back to your example.
> Even when quickly "rebooting" (read: increasing the reboot session
> counter fast), this should not be a problem. nine 9's is very big!
> My code uses the current-time, during initialisation, in seconds after
> 2002 (syslog-sign didn't existed before) and divide by 2.
>
> This will result in a reboot-session, that will wrap in the year
> 2600 (or about). And which can be started each 2 seconds.
>
> You can find my code on SF.net, or see below for a C-code fragment:
>
> --------
> GLOBAL int rebootSessionID = 0;
>
> int reboot_session_id(void)
> {
> if (rebootSessionID != 0) {
> if (gettimeofday(&now) != 0)
> rebootSessionID = 1 // it has to have a value
> else
> rebootSessionID= (now.tv_sec- ( (2002-1700) * 365 * 3600) ) / 2
> }
> return rebootSessionID;
> }
> ------
... this is where I should have done some "advanced math" ;) OK, I am
guilty...
> For a standalone commandline tool, you probably need more a bit more
> resolution. E.g. skip the "divide by 2". Most important is that value
> is unique for that session, for that invocation of that commandline
> tool. If that means it will wrap in "only a few years", let it
> be. It's not typical to have short rebootsessions. It means verifying
> the log, is hard to do anyhow !! Then is easy for delete all log of a
> reboot session (for a hacker). That can't be verified.
That is in fact an excellent point. So for my (unusual) command line
tool, I may be better of to use the day as reboot session id and keep it
the same during all of the day. Of course, I could miss an actual system
reboot, but I think that mapping would work fine for this bizzare
example. So I finally got my issue better solved than I asked for :)
Thanks,
Rainer
