Welcome to Squishdot Squishdot How-To Newbies Websites
 about
 search
 post article
 Documentation
 Mailing Lists
 Bug Tracking
 Development
 Installation
 Upgrading
 Download
 admin
 rdf

 main


The design of createID?
Squishdot Posted by Robb Shecter on Saturday January 11, 12:07AM, 2003
from the dept.

I just installed Squishdot, and while showing it to a co-worker, he pointed out that the message ids are simply the time since the epoc. I was really suprised to see that this is the case.
God knows why... - Ed. ;-)

This kind of thing often leads to security or concurrency problems.

Are there any guarantees that createId is threadsafe?

Aside from this problem, the software is great!

Thanks!

<  |  >

 

Related Links
  • Articles on Squishdot
  • Also by Robb Shecter
  • Contact author
  • The Fine Print: The following comments are owned by whoever posted them.
    ( Reply )

    :-P
    by Chris Withers on Monday January 13, 12:34PM, 2003
    I'm curious as to how this is a security vulnerability. Please explain...

    As for concurrency, part of the algorithm for creating IDs ensures that they're unique as needed.

    As for threadsafety, Zope (and ZODB in particular) gives you thread safety for free.

    Any more questions? ;-)

    Chris

    [ Reply to this ]
    • Re: :-P
      by Curtis "Ovid" Poe on Monday January 13, 06:00PM, 2003

      I can't comment on how this might be a security issue, but speaking from experience on working with some awful databases, I can say that using "time since the epoch" is a terrible choice for an identifier. Consider slashdot, to choose a less than random example. It's not unusual to see several posts in a long thread with the same timestamp. Were they to choose your model, there would need to be code added to deal with the special case of multiple people adding records at once. Then, you not only have to ensure that two people aren't posting at the same time, you also must ensure that, if they are posting at the same time, that the "unique" ids that are created for them might not be stepping on one another by tracking the state of the current unique ID. If 30 people tried to post at once in reply to the same thing, you must track 30 different unique ids. That's pushing into the code something that should be probably be handled in the database.

      Whenenever a special case must be represented in the code, this increases the chance for bugs and a better design decision is to choose a design which does not require said special case (if possible). For instance, I assume that the database that Squishdot uses supports some form of ID sequence or "auto-increment". This would be a better choice for IDs as it would be guaranteed to be unique without the need for extra code.

      Also, as Robb had noted to me, he sees that other programmers have noticed the "timestamp as id" and have started to assume that this will always be valid. What if the time on the server is off? What if it's decided in the future to change this? By using identifying information, an "unofficial API" has been created which the creators of Squishdot may not wish to support.

      And on a more positive note: Good job! It's nice to see what you folks have put together.


      [ Reply to this ]
      • :-P :-b
        by Chris Withers on Monday January 13, 06:12PM, 2003
        The python code that deals with the entire issue you're worrying about is:
            def createId(self):     
                id=int(time())     
                while self.data.has_key(id):     
                    id=id+1     
                return id     
        
        ...so stop getting your knickers in a twist. This code has been extremely thoroughly tested under some pretty high loads.

        Squishdot runs on Zope, which uses ZODB as its database. This fantastic object database takes care of 90% of the things you're worrying about.

        As for server time, if it's off when your posting is posted, however you record the date of posting will be off. So, it's kinda irrelevent.

        If people choose to assume it's some kind of API, they're kinda silly. There are documented API's for getting the date of posting. That said, I ain't ever changing it, so it'll only be a couple of seconds out, at most, anyway.

        And quit worrying about the id being a security hole. It isn't.

        Sheesh! If you like the product, don't worry! Check out the sites on which Squishdot is used. If there were problems as serious as you suggest, do you think they'd still be using it? ;-)

        [ Reply to this ]
        • Re: :-P :-b
          by Robb Shecter on Monday January 13, 07:15PM, 2003
          Hi,

          On security:

          At my last job, I learned the dangers of encoding meaningful information in database keys. Hackers were able to access web accounts of doctors, in part because the database key was a predictable value and easily guessable.

          I think this is why many people just don't do it if they don't have to; why expose yourself to potential problems? There are many more issues here - see C.J. Date's Relational Database Writings books.

          On concurrency:

          I don't know Zope well enough to understand how / where serialization is guaranteed. I see that security/access is explicitly coded in the module, but synchronization? Where is that specified? Are all Product calls syncrhonized by default? Hard to imagine - that'd be pretty inefficient.

          Also, I see a concurrency problem with the above code, even if access to it is synchronized. It does a check to see if the id exists in a dictionary, does not save it, and then exits, returning the new value, which (presumably) gets put into that same dictionary. Although, this now depends on how it's used. So, as far as I can tell, there are two problems with it:

          1. (Under synchronization) When one thread leaves the function, another thread can enter it, allowing it to arrive at the same new id before the first thread can save it in the dict.
          2. The function doesn't maintain the contract it seems to set out to: The correctness of the result depends on how callers use it. I'd prefer to have a function that (say) is guaranteed to always return a useable, unique id.
          So anyhow, since you wouldn't use the time info in the id - would you be interested in a patch that'd implement what we're thinking about? Robb
          [ Reply to this ]
          • Re: :-P :-b
            by Chris Withers on Monday January 13, 11:42PM, 2003
            On security: The whole point about a weblog is that users and web-spiders can find out these IDs easily, that's why they're all linked to. The various methods are anonymously accessible when they're supposed to be and not accessible at all when they're not, even if you know the ID or the method or the object you want to execute that method on.

            On concurrency: Go read up on ZODB. The application programmer gets all the protection you're looking for, for free!

            As for patches, quite frankly, I'm not really interested. I'm more than comfortable this code is bulletproof. If you aren't, well hey, no ones forcing you to use it ;-)

            Anyway, this is the last you'll hear from me on this thread.

            Chris


            [ Reply to this ]
        • Re: :-P :-b
          by Curtis "Ovid" Poe on Monday January 13, 08:10PM, 2003
          And quit worrying about the id being a security hole. It isn't.

          I'm not worrying that it's a security hole. As far as I can tell, there is no security issue here, though there could be functionality issues as described by Robb. Unless I misunderstand what is going on, the function is misnamed as it does not create an id. An id is expected to be unique and that guarantee does not appear to be there as the ID is not reserved at the time of creation.

          Check out the sites on which Squishdot is used. If there were problems as serious as you suggest, do you think they'd still be using it? ;-)

          Three words: "Matt's Script Archive". The scripts in his archive are some of the most popular Perl scripts in the world and are used all over the place. However, they are also incredibly poorly written and have been a source of numerous security holes. Popularity != quality :) Of course, that's not to say that your's is a poor quality product. I've not had a chance to look at the code base and do a review (and in any event, I don't know Python very well), so I hope this single issue is not interpreted as an attack on the overall system.


          [ Reply to this ]
          • Re: :-P :-b
            by Chris Withers on Monday January 13, 11:36PM, 2003
            You choose to use the code you use. Whether or not you use Squishdot is no skin off my nose, I'm pretty happy with the codebase.

            The ID is 100% ensured to be unique (and no, I'm not going to prove it, you go read up on transactional concurrency with ZODB. Clues though: look for ConflictError's, how they're retried and why this works).

            As for an attack on the overall system, I find it quite amusing that you're getting so het up on such a tiny non-issue. I'm going to reply to Rob's post but after that I'm gonna leave this thread be and go do something useful with my time ;-)

            cheers,

            Chris
            [ Reply to this ]

     
    The Fine Print: The following comments are owned by whoever posted them.
    ( Reply )

    Powered by Zope  Squishdot Powered
      "Any system that depends on reliability is unreliable." -- Nogg's Postulate
    All trademarks and copyrights on this page are owned by their respective companies. Comments are owned by the Poster. The Rest ©1999 Butch Landingin, ©2000-2002 Chris Withers.