Subject: RE: [nfsv4] Stringprep Compares

From: "Noveck, Dave" <[email-masked]>
Date: Wed, 16 Mar 2005 16:36:47 -0500

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.  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. 

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

On Wed, Mar 16, 2005 at 03:33:56PM -0500, Jim Rees wrote:
>   a) specify a normalization form
>   b) specify a way to negotiate the use of currently unassigned code
>      points (so NFSv4 can use them when they are assigned)
>   c) specify that the client is responsible for applying stringprep,
while
>      the server is responsible for verifying that the UTF-8 strings
sent
>      by the client are consistent with the required stringprep
profile,
>      but only on CREATEs -- the latter requires less computation and,
>      possibly storage and would be avoided in most situations.
> 
> a) is absolutely essential and should be done asap.
> 
> c) might be meddling in implementation details.

See below.

>                                                  Isn't it sufficient
to
> specify the character set (unicode) and normalization on the wire?

Yes.  For brand-new filesystems not accessed in any way other than
through NFSv4 this is the same as saying what I said in (c).

That is, clients MUST send stringprepped file names and servers MUST NOT
accept non-stringprepped names from clients.

Whether the spec should also say that the server MUST NOT send
non-stringprepped names is another story, but servers certainly MUST NOT
send non-UTF-8 names to clients.

For
> example, if a server is sharing its file store with other applications
(as
> is the case with the linux server) it may find some invalid file names
on
> disk even though it carefully checked all the names on creat.  So it
may
> want to do some validation or stringprep on readdir.

Saying anything about that in the spec would be meddling in
implementation details.  Consider two alternatives, among others,
available to the implementor: store stringprepped UTF-8 names on disk
and stringprep all creats from the local apps, not just from NFSv4
clients, OR stringprep on READDIRs.

> I suspect most clients and servers today do no validation or
stringprep on
> any names.  For the BSDs and maybe even for linux it isn't really
defined
> what the character set is either on disk or at the syscall interface.

Implementation details.

Nico
-- 

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

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

---

From: Nicolas Williams <[email-masked]>
Date: Wed, 16 Mar 2005 15:48:00 -0600

On Wed, Mar 16, 2005 at 04:36:47PM -0500, Noveck, Dave wrote:
> 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

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
--