Project

General

Profile

Bug #5860

NFSv4 server incorrectly processes linktext4 (symbolic link) data

Added by Albert Lee almost 5 years ago.

Status:
New
Priority:
Normal
Assignee:
-
Category:
nfs - NFS server and client
Start date:
2015-04-21
Due date:
% Done:

0%

Estimated time:
4.00 h
Difficulty:
Bite-size
Tags:
bite-size

Description

With #5761 we introduce the updated RFC 7531 definition of the NFSv4 XDR interface. Symbolic link contents are now explicitly stored in an opaque data type, linktext4. RFC 7530 has this description:

The contents of symbolic links (of type linktext4 in the XDR) MUST be treated as opaque data by NFSv4 servers. Although UTF-8 encoding is often used, it need not be.

Marcel writes:

The problem is that our implementation is even more complex than one would expect (or want): we do not treat the linktext4 as opaque data, nor UTF-8 string. The linktext4 in our NFS server implementation is subject of the character conversion; the nfscmd_convname() is called on it. So we cannot avoid the current UTF-8 assumptions, because the assumptions are a bit different. Having said that, it looks like the calls like utf8_to_str() on linktext4 are not correct (with my fix, and even without my fix), but we should deal with that separately (if we would do so). So I believe the typecasting, as I am suggesting in the fix, is the best way how to deal with that for now.


Related issues

Related to illumos gate - Bug #5761: nfs4_prot.x should be updated for RFC 7531Closed2015-03-28

Actions

History

#1

Updated by Albert Lee almost 5 years ago

  • Related to Bug #5761: nfs4_prot.x should be updated for RFC 7531 added

Also available in: Atom PDF