Bug 33809 - [patch] mount_nfs(8) has trouble with embedded ':' in path
Summary: [patch] mount_nfs(8) has trouble with embedded ':' in path
Status: Closed FIXED
Alias: None
Product: Base System
Classification: Unclassified
Component: bin (show other bugs)
Version: 4.5-PRERELEASE
Hardware: Any Any
: Normal Affects Only Me
Assignee: freebsd-bugs (Nobody)
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2002-01-12 11:20 UTC by Aaron Kaplan
Modified: 2019-01-23 04:56 UTC (History)
1 user (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Aaron Kaplan 2002-01-12 11:20:01 UTC
      try mounting a nfs share where the path contains a ':'

      root@www:~>mount_nfs 10.1.2.3:/u2/ftp/priv/mp3/Welle\:Erdball /mnt
      mount_nfs: bad net address 10.1.2.3:/u2/ftp/priv/mp3/Welle

      With all common ways to escape ':' in the shell it does not work
      Seems like mount_nfs cuts off the path at the first (even escaped)
      ':'.

Fix: When taking a look at /usr/src/sbin/mount_nfs/ \
       mount_nfs.c the problem seems to be at line 593:

       [ function: getnfsargs() ]
                 if ((delimp = strrchr(spec, ':')) != NULL) {
                               ^^^^^^^^^^ this gives a '\:' no chance.
        Neither does it take into account that I might have specified
        the path enclosed with single quotes "'" (e.g.
         mount_nfs hostname.com:'/my/path:rest/' /mnt


       A possible (probably not very good) solution seems to be to use
        strchr() (match for first occurence of ':'). At least this
       would fit to our common belief that the share name is seperated
       from the host name by the leftmost ':'.

       I tested it and it works. However I did not check for side effects.

       Hope it helped and was precise enough.
       Keep on ! great project



-       if ((delimp = strrchr(spec, ':')) != NULL) {
+       if ((delimp = strchr(spec, ':')) != NULL) {
                hostp = spec;
                spec = delimp + 1;
-       } else if ((delimp = strrchr(spec, '@')) != NULL) {
+       } else if ((delimp = strchr(spec, '@')) != NULL) {
                warnx("path@server syntax is deprecated, use server:path");
                hostp = delimp + 1;
        } else {--iwgRsj5FxfFznAqYixGSJ6VhlkspOlgiIbJ8G65tYevYuxZ7
Content-Type: text/plain; name="file.diff"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="file.diff"

--- mount_nfs.orig.c    Sat Jan 12 12:11:01 2002
+++ mount_nfs.c Sat Jan 12 12:11:47 2002
@@ -590,10 +590,10 @@
        size_t len;
        static char nam[MNAMELEN + 1];
How-To-Repeat: 	Create a directory on your nfs server containing a ':'.
        export it, kill -HUP mountd
        Try to mount it on a client machine.
Comment 1 dwmalone 2002-01-12 14:37:34 UTC
On Sat, Jan 12, 2002 at 12:18:55PM +0100, aaron wrote:
>        When taking a look at /usr/src/sbin/mount_nfs/ \
>        mount_nfs.c the problem seems to be at line 593:
> 
>        [ function: getnfsargs() ]
>                  if ((delimp = strrchr(spec, ':')) != NULL) {
>                                ^^^^^^^^^^ this gives a '\:' no chance.
>         Neither does it take into account that I might have specified
>         the path enclosed with single quotes "'" (e.g.
>          mount_nfs hostname.com:'/my/path:rest/' /mnt

If you put quotes or escape the colon on the command line, then
this will have been interpreted by your shell before mount_nfs is
run and so mount_nfs does not have to understand this. The reason
the last ':' is used is probably so that IPv6 addresses can be used
with mount_nfs (this would work in -current, but probably not on
stable).

I'm not sure what the best way to resolve this is - it may be "don't
use paths with colons in them". Another possibility would be to add
an extra flag to mount_nfs which lets you give the host name/address
seperately from the path.

	David.
Comment 2 jorge 2002-02-14 19:39:22 UTC
Not using ":" may not be optional.  Trying mount_nfs on a 'dos-like' server requires the ":" to identify the drive to be mounted on multi-drive systems.  Using strchr solved the problem for me; an extra flag sound like an alternative.

Jorge.
Comment 3 mux freebsd_committer freebsd_triage 2002-04-18 22:50:26 UTC
Responsible Changed
From-To: freebsd-bugs->mux

I will take care of this problem (related to PR/37230).
Comment 4 Mark Linimon freebsd_committer freebsd_triage 2011-06-23 19:04:42 UTC
Responsible Changed
From-To: mux->freebsd-bugs

mux has returned his commit bit for safekeeping.
Comment 5 Eitan Adler freebsd_committer freebsd_triage 2017-12-31 08:01:43 UTC
For bugs matching the following criteria:

Status: In Progress Changed: (is less than) 2014-06-01

Reset to default assignee and clear in-progress tags.

Mail being skipped
Comment 6 Oleksandr Tymoshenko freebsd_committer freebsd_triage 2019-01-23 04:56:58 UTC
This was solved by base r203490:

Introduce '[ipaddr]:path' notation.
Since the existing implementation searches ':' backward, a path which
includes ':' could not be mounted.  You can now mount such path by
enclosing an IP address by '[]'.
Though we should change to search ':' forward, it will break
'ipv6addr:path' which is currently working.  So, it still searches ':'
backward, at least for now.