Re: cvs commit: src/sys/geom/label g_label.c

From: Gordon Tetlow (gordon_at_tetlows.org)
Date: 08/19/05

  • Next message: Hajimu UMEMOTO: "[CFR] reflect resolv.conf update to running application" 
    Date: Thu, 18 Aug 2005 22:22:52 -0700
To: freebsd-arch@freebsd.org

    Pawel Jakub Dawidek wrote:

    >On Tue, Aug 16, 2005 at 05:18:49PM -0700, Doug Barton wrote:
    >+> Pawel Jakub Dawidek wrote:
    >+>
    >+> >Because '/' creates a directory and I want each label to be represented
    >+> >only by one file.
    >+>
    >+> I think what people are saying is that they like the directory creating behavior. Can you explain your rationale in more detail?
    >
    >Actually, I don't really care. All I wanted was one label to be represented
    >by one single file. That's all. For me, leaving it as it is just asks for
    >troubles.
    >
    >I can live without this change, really. This is something I'd like to ask
    >about our TRB, but unfortunately it was retired yesterday:)
    >
    >CCing to freebsd-arch@.
    >
    >The question(s) is(are): Should we allow '/' in labels or should we replace
    >it with something (eg. '_')? Maybe we should only deny labels with '/../'?
    >
    >
    When I wrote GEOM_VOL_FFS, I wrote it with the idea that you could make
    a heirarchy of providers in /dev/vol. Coming from an environment where
    it wasn't unusual for a single machine to have 30 to 40 disk available
    to it, it seemed natural that we should allow administrators the ability
    to define how they wanted things mapped out.

    Now that I have just gone back and looked at the code that I wrote, I
    didn't allow non-alphanumerics in the volume name (although I actually
    didn't check it when creating the provider). I seem to recall making
    that decision specifically to get around the ../ tree traversal.

    Anyway, I think it comes down to tools, not policy. I think "/" should
    be allowed.

    -gordon
    _______________________________________________
    freebsd-arch@freebsd.org mailing list
    http://lists.freebsd.org/mailman/listinfo/freebsd-arch
    To unsubscribe, send any mail to "freebsd-arch-unsubscribe@freebsd.org"

  • Next message: Hajimu UMEMOTO: "[CFR] reflect resolv.conf update to running application"

    Relevant Pages