Making a time structure associated with the directory structure
Nifty Hat Mitch
mitch48 at sbcglobal.net
Sun Aug 29 01:15:31 UTC 2004
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
More information about the fedora-list
mailing list