Subject: RE: [nfsv4] Stringprep Compares

From: "Noveck, Dave" <[email-masked]>
Date: Wed, 16 Mar 2005 17:03:45 -0500

> None of the stringprep profiles listed in section 11 mention symbolic
> links in their applicability statements.

They don't have to.

Note: 

   linktext4       typedef utf8str_cs      linktext4;
                   Symbolic link contents

just the same as 

   component4      typedef utf8str_cs      component4;
                   Represents path name components

and 

   Every use of the utf8str_cs type definition in the NFS version 4
   protocol specification follows the profile named nfs4_cs_prep.

and

   The utf8str_cs type is a case sensitive string of UTF-8 characters.
   Its primary use in NFS Version 4 is for naming components and
   pathnames.

Doesn't say "sole use".  Sigh!

> Yes, you're right to be afraid of what happens with symlinks here, but
> don't be too afraid

Right now, I'm terrified.

-----Original Message-----
From: Nicolas Williams [mailto:[email-masked]] 
Sent: Wednesday, March 16, 2005 4:48 PM
To: Noveck, Dave
Cc: Jim Rees; [email-masked]
Subject: Re: [nfsv4] Stringprep Compares

On Wed, Mar 16, 2005 at 04:36:47PM -0500, Noveck, Dave wrote:
> One thing that needs to be added to this discussion is that
> not only filenames but also the contents of symlinks are
> specified in RFC3530 as UTF-8.

None of the stringprep profiles listed in section 11 mention symbolic
links in their applicability statements.

>                                 I don't know of anyone
> right now that enforces that on either the creation or
> read side.  My knowledge of stringprepping is somewhat
> limited but I do know enough to be very afraid about the
> implications for symlinks stored by v2/v3, by versions
> of v4 before v4 was stringprepified.
> 
> Am I wrong to be afraid?  If I knew more about this would
> I be more or less afraid?  Is this a case in which the 
> only thing I have to fear is fear itself?  Probably not. 

Symbolic link content is totally free-form, as far as I can tell.

But often symbolic link content is meant to be valid paths, which means
that in those cases it should be stringprepped.

Yes, you're right to be afraid of what happens with symlinks here, but
don't be too afraid -- we really have to, er, normalize the rest of the
NFSv4 I18N situation first.

Nico
-- 

_______________________________________________
nfsv4 mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/nfsv4

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 16 Mar 2005 16:11:29 -0600

>    linktext4       typedef utf8str_cs      linktext4;

Ah.  Since symlink contents is kinda free-form this should probably be
changed to be opaque<>.  It probably doesn't matter much though.

> Right now, I'm terrified.

Of symlinks?  Why?  The bigger filesystem I18N picture is more
terrifying still :(