gnu-system-discuss
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Kitten


From: Alfred M. Szmidt
Subject: Re: Kitten
Date: Mon, 16 May 2005 21:04:12 -0400

   [...] you run into a couple of problems that I am going to explain
   here...

Soeren, you haven't explained the problems (unless it is hidden in
your message) that you ran into.  Could you list the questions that
you are having problems with?

   The term "delimiter" is a bit confusing, however, because it does
   not indicate the end of a file but its beginning.

There is nothing confusing with the word delimiter in this context, it
indicates not only the start of the next section, but it also
indicates the end of the previous section.

   What will happen if someone just removes a delimiter from the file
   content?

Then we write the content to the previous file, if no such file exists
(i.e. we remove a delimiter on line 0), then we write to the following
file.  If neither exists, we write it to the translated file.

That should cover all cases in a quite intuitive manner.

   Remaining on the strict definition above how it should work, you
   cannot solve this.

What strict definition?

   Consider a tool written in ANSI C that manipulates a file in a way
   that includes cutting some bytes at the end.  Unless these bytes
   contain a delimiter, everything seems all right.  But the usual way
   how to do this in ANSI C is to read the content of the file and
   then truncate it completely.  Obviously, we removed all the
   delimiters that way and kitten will get *really* confused.

You mean that your current version gets confused, right?

   1. One might define that all the tailing empty files in the
      conkittenation are not listed.

Ugly.

   2. A much more enhanced approach is to make the delimiters
      "sensitive": by changing the delimiter content, you can choose a
      file to join the conkittenation.

I guess that this is what my rules above are, but with a very
confusing name and you didn't describe how this really works.

      Obviously, this is a security issue: by making one file writable
      to somebody, you make *every* file that you can control
      writable.

Just check the permission on each file before writting any data back,
and if one or more files can't be written to, spit out ENOPERM.

I note that you haven't noted the scenarios that Wolfgang wrote about
in his mail (May 12th, 2004, subject: Write support for composed
configuration files).  You should read that, if you haven't already
done so.  If you want I can forward it again to the list...


Happy hacking!




reply via email to

[Prev in Thread] Current Thread [Next in Thread]