Bug 25067

> >Fix:

This is a small patch for it:

--- /old/cd9660_vfsops.c     Sun Feb 18 22:28:23 2001
+++ /usr/src/sys/isofs/cd9660/cd9660_vfsops.c   Sun Feb 18 22:26:51 2001
@@ -188,6 +188,12 @@ cd9660_mount(mp, path, data, ndp, p)
        mode_t accessmode;
        struct iso_mnt *imp = 0;
 
+       /*
+        * Do not allow paths-names bigger than MNAMELEN characters.
+        */
+       if (strlen(path) >= MNAMELEN)
+               return (ENAMETOOLONG);
+
        if ((mp->mnt_flag & MNT_ROOTFS) != 0) {
                return (iso_mountroot(mp, p));
        }

--- /old/vfs_syscalls.c      Sun Feb 18 22:28:23 2001
+++ /usr/src/sys/kern/vfs_syscalls.c    Sun Feb 18 22:27:12 2001
@@ -133,6 +133,13 @@ mount1(p, uap, segflag)
 
        if (usermount == 0 && (error = suser(p)))
                return (error);
+
+       /*
+        * Do not allow paths-names bigger than MNAMELEN characters.
+        */
+       if (strlen(uap->path) >= MNAMELEN)
+               return (ENAMETOOLONG);
+
        /*
         * Do not allow NFS export by non-root users.
         */


This works for cdrom-based and for "general" filesystems (ufs,
msdos, procfs..., actually, everything handled in the kernel)

As soon as you try to mount something like you gave in your example
now it gives:

[~] root@p6>mount /dev/vn0c /a/very_very_very_very_very_very_very_very_long_pathname_with_more_than_80_characters
mount: File name too long

Maximum lenght of a mount-path (for i386) is 79 characters (buffer
is 80, one for the padding 0), for alpha it's 71 characters (untested,
but I assume it's the same kind of idea)

Edwin

-- 
Edwin Groothuis   |           Interested in MUDs? Visit Fatal Dimensions:
mavetju@chello.nl |                     http://fataldimensions.nl.eu.org/
------------------+               telnet://fataldimensions.nl.eu.org:4000

Comment 2 Adrian Chadd 2001-03-02 15:57:50 UTC

State Changed
From-To: open->closed



Fixed in revision 1.180 (and fixed properly in revision 1.181) 
of src/sys/kern/vfs_syscalls.c .

Comment 3 Adrian Chadd 2001-03-04 18:03:43 UTC

State Changed
From-To: closed->open


As someone (Cyrille) rightfully pointed out, I still have to 
MFC this out to RELENG_4. 

Comment 4 Adrian Chadd 2001-03-04 18:03:43 UTC

Responsible Changed
From-To: freebsd-bugs->freebsd-bugs

Make sure I mfc my changes

Comment 5 Adrian Chadd 2001-03-04 18:05:56 UTC

Responsible Changed
From-To: freebsd-bugs->adrian

Hrm. The last attempted change didn't quite reassign the PR to me.

Adrian,

is there any chance to get this PR MFC before 4.3 (sounds good :) is released ?

thanks in advance.

Cyrille.
--
home: mailto:clefevre@poboxes.com   UNIX is user-friendly; it's just particular
work: mailto:Cyrille.Lefevre@edf.fr   about who it chooses to be friends with.

Comment 7 Adrian Chadd 2001-03-17 15:56:11 UTC

On Sat, Mar 17, 2001, Cyrille Lefevre wrote:
> Adrian,
> 
> is there any chance to get this PR MFC before 4.3 (sounds good :) is released ?
> 
> thanks in advance.

Well, I could, but there were some concerns over how "good" a solution
it was.

If people don't mind, I'll spark up a patch to enforce the limitation
for mount() and umount() without my VFS_MOUNT() interface change.



Adrian

-- 
Adrian Chadd			"Programming is like sex:
<adrian@freebsd.org>		   One mistake and you have to support for
				    a lifetime." -- rec.humor.funny

Comment 8 Mark Linimon 2004-09-13 06:44:58 UTC

Responsible Changed
From-To: adrian->freebsd-bugs

With bugmeister hat on, reassign from recently inactive committer.

Comment 9 iedowse 2005-04-17 23:49:13 UTC

State Changed
From-To: open->patched


This has been fixed in both 5.x and -CURRENT.

Comment 10 Matteo Riondato 2005-07-31 13:04:31 UTC

State Changed
From-To: patched->closed

Fixed and MFCed