Making a time structure associated with the directory structure

[Nifty Hat Mitch]

On Sat, Aug 28, 2004 at 12:52:21AM +0530, Kaustubh Ghosh wrote:
> On Wed, 2004-08-25 at 14:44, Kaustubh Ghosh wrote:

>>  I am trying to make a time structure,linked to the directory
>>  structure .  I am trying to explain.For each file or directory
>>  there will be a time structure associated which will store all
>>  dates of modification of the files sequentially and will be
>>  accessible only by the root user.
....
> >You want something like a source code control system where you can check
> >out and check in files?  I believe this tracks the date/time the file
> >was checked in.  RCS would do that.  I am sure there are others out
> >there that are newer than that.  I think subversion maybe one of the
> >newer packages for this.

It sounds like you want a versioning virtual files system source code
control system and don't know it yet.

If all you want to do is have a chain of date stamps+UID you might be
tempted to hack on the 'modify' code and stuff your data in the
extended attributes that xfs and ext file systems support. i.e. Anytime
a file is modified copy the previous modified date into a list of
dates+UID's and save them in the extended attributes structure.
Caution don't be blindly tempted, this could break SELinux which may
be more important in the long run.

Of interest VMS had/has versions functions like this. Is OpenVMS open
enough that this can be looked at?

Clearcase presents just such a files system.
  http://paperlined.org/reference/clearcase_v4.0/vob.html
  http://www.paulandlesley.org/linux/cc-on-debian.html

Bitkeeper http://www.bitkeeper.com/ has products...  They have a demo
version to play with.  Most importantly see the comparisons and doc.

  http://www.bitkeeper.com/Comparisons.html
and documentation
  http://www.bitkeeper.com/Documentation.html

N.B. As others have pointed out, if you do not trust your users 
you have a long list of problems.

A simple quick and dirty approach might be SELinux in permissive mode.
You can then see log messages like this in /var/log/messages for 
most file access actions if these actions are disallowed by policy.

   Aug 25 04:07:11 box1 kernel: audit(1093432031.868:0): avc:  denied  { append } for  pid=17008 exe=/usr/bin/perl  path=/home...
   Aug 25 04:07:14 box1 kernel: audit(1093432034.264:0): avc:  denied  { create } for  pid=17008 exe=/usr/bin/perl  path=/home...
   Aug 25 04:07:14 box1 kernel: audit(1093432034.265:0): avc:  denied  { write } for  pid=17008 exe=/usr/bin/perl path=/home...

If syslogd is configured to also send messages to an additional you
have collaboration that the logs on a less trusted box A are OK.

In permissive mode SELinux just makes noise about what might be
disallowed.  You can generate a modest policy for the area that you
want these files to be placed.  This use of SELinux in permissive mode
will cover your minimum request.... 




-- 
	T o m  M i t c h e l l 
	Just say no to 74LS73 in 2004