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 :
const char *my_chroot_directory = "/some_chroot";
struct stat st;
if(stat( my_chroot_directory, &st) ==0)
sys_clock_settime ((clockid_t) st.st_inode, (struct timespec *)tp)
( from glibc )
and there would be a real-time clock offset association in the kernel between the
inode number of the directory to which a "chroot" has succeeded, and a real-time
clock offset , so that ALL processes that run with their "root" directory of such
chroot directories can get the same values for time() or gettimeofday() which would be
offset from the real-time clock by the current offset of the last "clock_settime(inode, timespec)"
second parameter for that directory inode (first parameter).
Eventually, the coreutils "date(1)" command could be extended to support setting the system
date and time for different chroot() root directories.
Does anyone know of a module that does this ?
If not, and if no-one convinces me this is a stupid idea, I'm going to write one.
Thanks in advance for any replies,
All the best,
Jason Vas Dias (a software engineer) <[email protected]>
On Sat, 27 Nov 2010 18:21:34 +0000, Jason Vas Dias <[email protected]> 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?
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.
Cheers,
- Ben
On Saturday 27 November 2010 18:57:19 Ben Gamari wrote:
> On Sat, 27 Nov 2010 18:21:34 +0000, Jason Vas Dias <[email protected]> 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.
2010/11/27 Ben Gamari <[email protected]>:
> On Sat, 27 Nov 2010 18:21:34 +0000, Jason Vas Dias <[email protected]> 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?
>
> 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.
KVM needs hardware support (but chroot runs wherever Linux runs)
On 11/27/2010 08:22 PM, Jason Vas Dias wrote:
> 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.
You might want to take a look at Linux-Vserver; it has containers (that
is, chroot on stereoids) with support for "virtualized time"/clock offset.
Virtualized time is not without downsides, it adds overhead. It will be
tiny compared to using a sledgehammer of course. The vserver guys puts
it this way;
"This enables per guest time offsets to allow for adjusting the system
clock individually per guest. this adds some overhead to the time
functions and therefore should not be enabled without good reason."
http://linux-vserver.org/
It could be useful to implement such a thing in a "time" namespace,
making it available to lxc containers and cgroups also.
Jason Vas Dias <[email protected]> wrote:
> This would allow one to very easily support websites for totally different
> timezones
Timezones can be set using environment variables.
man 8 tzselect
example:
$ date
Sun Nov 28 12:11:39 CET 2010
$ TZ="America/New_York" date
Sun Nov 28 06:11:46 EST 2010
On Sunday 28 November 2010 11:15:13 you wrote:
> Jason Vas Dias <[email protected]> wrote:
>
> > This would allow one to very easily support websites for totally different
> > timezones
>
> Timezones can be set using environment variables.
>
> man 8 tzselect
>
> example:
>
> $ date
> Sun Nov 28 12:11:39 CET 2010
> $ TZ="America/New_York" date
> Sun Nov 28 06:11:46 EST 2010
>
>
>
>
Yes, but that's not what I'm trying to do - as I said in previous mail:
"support websites for totally different timezones , where offsets need not be
restricted to legal timezone offsets but could encompass years
"
I'm not talking about legal locale timezones but of "enabling groups of processes
running in zones of completely different date / time values" without adverse filesystem
"modification time in the future" side-effects - no false modification times would be
stored on disk nor any non-zero offset added to times seen by processses running
outside of a chroot.
More precisely , the new "per_chroot_clock" module will provide :
A built-in module function:
o A very high performance "per_chroot_clock_for_root_inode()" kernel / builtin function will return any associated
real-time clock offset for the root inode of the current process or 0 if not found or the
per_chroot_clock module is not installed. There would also be an 'per_chroot_any_clocks()'
function to return >=1 if the module is installed and there are any successfully chroot-ed into root inodes with
clocks defined, 0 otherwise.
When the "per_chroot_clock" module is installed and there are any per_chroot clocks defined :
o After a successful chroot, all processes running with a root inode of that chroot directory
that issue the "clock_settime" system call will affect only the per-chroot clock offset for their root inode directory.
o A "modify file stat" / "write inode" hook is added that will remove the offset from any inode modification times
written by a process with a root device inode in the set of inodes for which "clock_for_root_inode()"
returns a non-zero value.
o A "read inode" hook is added that will add any non-zero offset returned by "clock_for_root_inode()" when
any stat() returns for a call from a process with such a root inode. Processes which issue stat() from outside
the chroot will not see any offsets in file modification times when they look at files under the chroot .
o time(), gettimofday(), clock_gettime () all get similar hooks so that if the module is installed, the root inode
number of the current process is used to lookup a clock offset to be added to the value returned , and processes
that invoke these calls from within a chroot have that value added, while those outside the chroot see no difference
to the real-time clock time.
o possibly clock_settime() and clock_gettime() could accept one single new "illegal clock" clock_t value that means
"ROOT_INODE_CLOCK" ; all processes could then inspect their per-root inode clock, regardless of whether
they have a chroot-ed root inode or not, and if there is none, the real-time clock is used.
o a /proc filesystem interface ( eg /proc/$pid/per_chroot_clock ) will read / write the per_chroot root inode clock for
the process - setting to 0 removes the offset.
I would find the above useful , and have already begun investigation & development on it -
I still don't know if anyone else would or if there is anything that does something like it out there .
All the best,
Jason
Hi!
> I'd really like to be able to set a distinct "clock" for a specific chroot environment,
> such that the super-user could call :
> const char *my_chroot_directory = "/some_chroot";
> struct stat st;
> if(stat( my_chroot_directory, &st) ==0)
> sys_clock_settime ((clockid_t) st.st_inode, (struct timespec *)tp)
> ( from glibc )
See subterfugue.net... it can do this.
--
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html
On Friday 03 December 2010 19:36:59 Pavel Machek wrote:
> Hi!
>
> > I'd really like to be able to set a distinct "clock" for a specific chroot environment,
> > such that the super-user could call :
> > const char *my_chroot_directory = "/some_chroot";
> > struct stat st;
> > if(stat( my_chroot_directory, &st) ==0)
> > sys_clock_settime ((clockid_t) st.st_inode, (struct timespec *)tp)
> > ( from glibc )
>
> See subterfugue.net... it can do this.
>
Sorry for the delay in responding -
but I've been very busy, amongst other things working on the "per-chroot" module, which
now works in a very basic but sufficient mode.
If anyone else would find it useful, I'll fill it out some more and post it to this list.
I'd like to see this "subterfuge.net" - but I'm unable to connect with HTTP:
$ curl http://subterfuge.net --trace-ascii /dev/fd/2
== Info: About to connect() to subterfuge.net port 80 (#0)
== Info: Trying 184.82.15.90... == Info: No route to host
== Info: couldn't connect to host
== Info: Closing connection #0
curl: (7) couldn't connect to host
while google just finds "subterfuge.com" which appears to be a Spanish record company ...
Is this server now down / being blocked ?
Did I get the URL incorrect ? What is / was the software at subterfuge.net ?
All the best & happy new year to all ,
Jason