Re: per-chroot clock module ?

From: Jason Vas Dias
Date: Sat Nov 27 2010 - 14:22:58 EST


On Saturday 27 November 2010 18:57:19 Ben Gamari wrote:
> On Sat, 27 Nov 2010 18:21:34 +0000, Jason Vas Dias <jason.vas.dias@xxxxxxxxx> wrote:
> > Greetings -
> >
> > Sorry in advance if this is a stupid idea, but -
> >
> > I'd really like to be able to set a distinct "clock" for a specific chroot environment,
> > such that the super-user could call :
> > [snip]
>
> It certainly doesn't sound like a particularly good idea to me. This
> would add great complexity to the kernel while having very few
> users. Perhaps there's something I haven't considered but I can't think
> of any good applications for this sort of functionality. Do you have
> something in particular in mind?

I'm not sure that it need be that complex -
o kernel knows chroot() has succeeded so adds the inode of that directory to a "inode <-> clock_offset" mapping
initialized to 0.
o this mapping could perhaps also be used to provide other future per-chroot specific features - as for instance
a per-chroot list of extra acceptable binary executable formats ?
o clock_gettime() and gettimeofday() and time() and clock_settime() are modified to see if the root device inode
number has a non-zero real-time clock offset, and, if so, apply it to the real-time clock returned or in the case
of clock_settime(), set the associated offset to a non-zero value.

RE: why ?
This would allow one to very easily support websites for totally different timezones , where offsets need not be
restricted to legal timezone offsets but could encompass years - also nice if you want to run applications whose
license key has expired . Also very easy to support multiple instances of cron(1) running in different timezones.
In any case, the module would ensure that the time the kernel sees internally for all processes is the actual real-time
clock value; only processes which have their root directory in one of the special chroot directories would get
a different gettimeofday() or clock_gettime() value .

>
> It seems like what you want here is simple virtualization. Have you
> considered KVM? The closest thing to your request currently upstream is
> containers, although I'm unsure of whether a container can be created
> with an independent clock. Might be something to look into.
>

To me, using virtualization to solve this problem is like using a sledgehammer to crack a nut,
particularly if the optimal performance of the processes running in such chroot environments
is of paramount importance.

> Cheers,
>
> - Ben
>

Thanks for your comments, but I think it is still a good idea and I'm investigating now -
it doesn't seem to need to be too complex to me.

All the best,
Jason.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/