linux-kernel - Re: per-chroot clock module ?

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-Id: <201011271922.45611.jason.vas.dias@gmail.com>
Date:	Sat, 27 Nov 2010 19:22:45 +0000
From:	Jason Vas Dias <jason.vas.dias@...il.com>
To:	Ben Gamari <bgamari@...il.com>
Cc:	linux-kernel@...r.kernel.org
Subject: Re: per-chroot clock module ?

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@...il.com> 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@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/