NetBSD Problem Report #48852
From martin@duskware.de Fri May 30 07:11:27 2014
Return-Path: <martin@duskware.de>
Received: from mail.netbsd.org (mail.netbsd.org [149.20.53.66])
(using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits))
(Client CN "mail.netbsd.org", Issuer "Postmaster NetBSD.org" (verified OK))
by mollari.NetBSD.org (Postfix) with ESMTPS id 5B297A567C
for <gnats-bugs@gnats.NetBSD.org>; Fri, 30 May 2014 07:11:27 +0000 (UTC)
Date: Fri, 30 May 2014 09:11:23 CEST
From: martin@NetBSD.org
Reply-To: martin@NetBSD.org
To: gnats-bugs@NetBSD.org
Subject: CD9660 RockRidge: device files not properly handled
X-Send-Pr-Version: 3.95
>Number: 48852
>Category: kern
>Synopsis: Either the cd9660 file system or makefs mishandle device nodes
>Confidential: no
>Severity: critical
>Priority: high
>Responsible: kern-bug-people
>State: closed
>Class: sw-bug
>Submitter-Id: net
>Arrival-Date: Fri May 30 07:15:00 +0000 2014
>Closed-Date: Fri May 30 13:15:45 +0000 2014
>Last-Modified: Fri May 30 13:50:00 +0000 2014
>Originator: Martin Husemann
>Release: NetBSD 6.99.43
>Organization:
The NetBSD Foundation, Inc.
>Environment:
System: NetBSD night-owl.duskware.de 6.99.43 NetBSD 6.99.43 (NIGHT-OWL) #256: Mon May 26 09:45:23 CEST 2014 martin@night-owl.duskware.de:/usr/src/sys/arch/amd64/compile/NIGHT-OWL amd64
Architecture: x86_64
Machine: amd64
>Description:
As far as I understand, the CD9660 file system with rockridge
extensions should be able to represent device nodes.
When testing, I found it only partly works: node type (c or b) is
properly preserved, but major/minor all get set to 0. This leads
to funny effects, as /dev/null is now the same as /dev/console (just
to mention one of the less critical ones).
>How-To-Repeat:
(as root, for MAKEDEV to work) do:
mkdir cdrom
mkdir cdrom/dev
cp /dev/MAKEDEV cdrom/dev
( cd cdrom/dev && sh ./MAKEDEV all )
makefs -t cd9660 -o rockridge test.iso cdrom
rump_cd9660 ./test.iso /mnt
ls -l /mnt/dev/console /mnt/dev/null
>Fix:
n/a
>Release-Note:
>Audit-Trail:
From: "Thomas Schmitt" <scdbackup@gmx.net>
To: gnats-bugs@NetBSD.org
Cc:
Subject: Re: kern/48852 CD9660 RockRidge: device files not properly handled
Date: Fri, 30 May 2014 10:35:02 +0200
Hi,
(Please Cc: me with replies, as i am not subscribed to kern
bugs. If a bystander can cause this bug thread to show up in
my mail box, then please do.)
I am currently enhancing cd9660 for multi-session and large
data files. In the course of this i did test block device
reading through ISO 9660 + Rock Ridge, with an ISO created
by my program xorriso (pkgsrc package libisoburn [1]).
The device file is shown by ls -l as
br-------- 1 thomas operator 0, 12 May 14 14:33 /mnt/iso/dev/wd1e
and delivers data which match the MD5 of the same amount
read directly from the original /dev/wd1e
brw-r--r-- 1 root operator 0, 12 May 14 14:33 /dev/wd1e
Being a competitor of makefs(1), i will not flatly point to it
now, before i can show a culprit in source code.
Nevertheless it is already known to produce faulty Rock Ridge
information.
E.g. if you load NetBSD-6.1.3-i386.iso in xorriso, you get
libisofs: WARNING : Invalid TF entry
libisofs: NOTE : > Caused by: Wrong or damaged Rock Ridge entry
A problem with device numbers would be in PN entries, though.
To produce a test ISO by xorriso:
xorriso \
-outdev /dvdbuffer/dev_wd1e.iso \
-map /dev/wd1e /dev/wd1e \
-chown thomas /dev/wd1e -- \
-chmod a-wx,go-r,u+r /dev/wd1e --
usable by
vnconfig -c vnd0 /dvdbuffer/dev_wd1e.iso
mount_cd9660 /dev/vnd0d /mnt/iso
ls -l /mnt/iso/dev
yields
br-------- 1 thomas operator 0, 12 May 14 14:33 wd1e
(It is dangerous to omit -o nodev when mounting ISO with valid
device nodes as superuser. I reduced the risk by taking away
permissions inside the ISO.)
The content seems ok:
$ dd if=/mnt/iso/dev/wd1e bs=2048 count=1000 | md5
50e4800cfae73e103eda08dfa061b6da
$ dd if=/dev/wd1e bs=2048 count=1000 | md5
50e4800cfae73e103eda08dfa061b6da
I will now have a look into makefs (which i cannot compile
due to API problems between NetBSD-6.1.3 and 6.99.40).
Have a nice day :)
Thomas
[1] If not from pkgsrc, you may get a xorriso tarball from
http://scdbackup.sourceforge.net/xorriso-1.3.6.pl01.tar.gz
Compile by
tar xzf xorriso-1.3.6.pl01.tar.gz
cd xorriso-1.3.6
./configure && make
Then runnable without installation as
xorriso/xorriso ...arguments...
From: "Thomas Schmitt" <scdbackup@gmx.net>
To: gnats-bugs@NetBSD.org
Cc:
Subject: Re: kern/48852 CD9660 RockRidge: device files not properly handled
Date: Fri, 30 May 2014 11:14:27 +0200
The problem is reproducible on my 6.99.40:
mknod /home/thomas/test/wd1e b 0 12
chmod u+r,go-r,a-wx /home/thomas/test/wd1e
cd /home/thomas
ls -l test
yields
br-------- 1 root users 0, 12 May 30 08:52 wd1e
But
makefs -t cd9660 -o rockridge test.iso test
xorriso -indev test.iso -lsl / --
yields
br-------- 1 0 100 0,0 May 30 08:52 'wd1e'
So the problem is in makefs and not in cd9660.
-----------------------------------------------------------------------
Related source code is in cd9660/iso9660_rrip.c:
if (node->node->inode != NULL &&
((S_ISCHR(node->node->inode->st.st_mode) ||
S_ISBLK(node->node->inode->st.st_mode)))) {
attr =
cd9660node_susp_create_node(SUSP_TYPE_RRIP,
SUSP_ENTRY_RRIP_PN, "PN",
SUSP_LOC_ENTRY);
cd9660node_rrip_pn(attr, node->node);
TAILQ_INSERT_TAIL(&node->head, attr, rr_ll);
}
and
int
cd9660node_rrip_pn(struct ISO_SUSP_ATTRIBUTES *pn_field, fsnode *fnode)
{
pn_field->attr.rr_entry.PN.h.length[0] = 20;
pn_field->attr.rr_entry.PN.h.version[0] = 1;
if (sizeof (fnode->inode->st.st_dev) > 32)
cd9660_bothendian_dword((uint64_t)fnode->inode->st.st_dev >> 32,
pn_field->attr.rr_entry.PN.high);
else
cd9660_bothendian_dword(0, pn_field->attr.rr_entry.PN.high);
cd9660_bothendian_dword(fnode->inode->st.st_dev & 0xffffffff,
pn_field->attr.rr_entry.PN.low);
return 1;
}
sizeof (fnode->inode->st.st_dev) > 32 looks strange.
Did the programmer mean bits rather than bytes ?
But a bug here would affect the major device number, which is
0 anyway.
The numbers 20 and 1 comply to RRIP-1.12.
cd9660_bothendian_dword() is frequently used in makefs.
A bug of this would show up at other ISO 9660 aspects too.
So something undesirable must have happened to the dev_t numbers.
------
cd9660/iso9660_rrip.h:
typedef struct {
ISO_SUSP_HEADER h;
u_char high [ISODCL(5,12)];
u_char low [ISODCL(13,20)];
} ISO_RRIP_PN;
This layout complies to RRIP-1.12 (in the web as e.g. rrip128.pdf).
-----------------------------------------------------------------------
My attempts to compile /usr/src/usr.sbin/makefs fail with
cd9660.o: In function `cd9660_level2_convert_filename':
cd9660.c:(.text+0x271): undefined reference to `_ctype_tab_'
which seems to be an incompatibility between NetBSD-6.1.3 from
binary packages and /usr/src from CVS.
So i cannot insert a few printf() here to find out which values
are seen and what code branch is executed.
From: "Thomas Schmitt" <scdbackup@gmx.net>
To: gnats-bugs@NetBSD.org
Cc:
Subject: Re: kern/48852 CD9660 RockRidge: device files not properly handled
Date: Fri, 30 May 2014 13:46:49 +0200
Further examinations:
A hex editor shows that the PN entry in test.iso indeed bears 0,0
as high and low number. ("high" and "low" is not "major", "minor",
but just high 32 bits and low 32 bits of dev_t.)
The "sizeof() > 32" in makefs/cd9660/iso9660_rrip.c is surely wrong.
It should be 4.
But the macros "major", "minor", "makedev" in <sys/types.h> show
that major,minor numbers 0,12 should be encoded as high=0,low=12:
#define makedev(x,y) ((dev_t)((((x) << 8) & 0x000fff00) | \
(((y) << 12) & 0xfff00000) | \
(((y) << 0) & 0x000000ff)))
I.e. the wrong condition would cause damage with devices which
have high minor numbers. But not to the major number and not to
minor numbers below 256.
But i do see damage with 0,12.
From: "Thomas Schmitt" <scdbackup@gmx.net>
To: gnats-bugs@NetBSD.org
Cc:
Subject: Re: kern/48852 CD9660 RockRidge: device files not properly handled
Date: Fri, 30 May 2014 14:28:08 +0200
The problem is in stat.st_dev versus stat.st_rdev.
I will send a patch proposal.
------------------------------------------------------------
Obviously the compile obstacle is not that /usr/include
would be included, but that libc is linked from userland.
An external variable used by macros of
/usr/src/sys/sys/ctype_inline.h
was not found at link time.
The remedy was to hack /usr/src/sys/sys/ctype_inline.h and
to define standalone versions of
isdigit islower isupper tolower toupper isprint isspace
Not really clean style:
makefs compilation fetches kernel source
/usr/src/sys/fs/udf/udf_osta.c
and robs other binaries
/usr/src/usr.sbin/mtree/spec.c
From: "Thomas Schmitt" <scdbackup@gmx.net>
To: gnats-bugs@NetBSD.org
Cc:
Subject: Re: kern/48852 CD9660 RockRidge: device files not properly handled
Date: Fri, 30 May 2014 14:38:27 +0200
--- usr.sbin/makefs/cd9660/iso9660_rrip.c.orig 2013-07-30 16:02:23.000000000 +0000
+++ usr.sbin/makefs/cd9660/iso9660_rrip.c 2014-05-30 12:25:40.000000000 +0000
@@ -657,13 +657,14 @@ cd9660node_rrip_pn(struct ISO_SUSP_ATTRI
pn_field->attr.rr_entry.PN.h.length[0] = 20;
pn_field->attr.rr_entry.PN.h.version[0] = 1;
- if (sizeof (fnode->inode->st.st_dev) > 32)
- cd9660_bothendian_dword((uint64_t)fnode->inode->st.st_dev >> 32,
- pn_field->attr.rr_entry.PN.high);
+ if (sizeof (fnode->inode->st.st_rdev) > 4)
+ cd9660_bothendian_dword(
+ (uint64_t)fnode->inode->st.st_rdev >> 32,
+ pn_field->attr.rr_entry.PN.high);
else
cd9660_bothendian_dword(0, pn_field->attr.rr_entry.PN.high);
- cd9660_bothendian_dword(fnode->inode->st.st_dev & 0xffffffff,
+ cd9660_bothendian_dword(fnode->inode->st.st_rdev & 0xffffffff,
pn_field->attr.rr_entry.PN.low);
return 1;
}
From: "Martin Husemann" <martin@netbsd.org>
To: gnats-bugs@gnats.NetBSD.org
Cc:
Subject: PR/48852 CVS commit: src/usr.sbin/makefs/cd9660
Date: Fri, 30 May 2014 13:14:48 +0000
Module Name: src
Committed By: martin
Date: Fri May 30 13:14:48 UTC 2014
Modified Files:
src/usr.sbin/makefs/cd9660: iso9660_rrip.c
Log Message:
PR kern/48852 (which should have been bin/ in retrospect): apply patch
from Thomas Schmitt to fix rockridge encoding of device nodes.
To generate a diff of this commit:
cvs rdiff -u -r1.13 -r1.14 src/usr.sbin/makefs/cd9660/iso9660_rrip.c
Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.
State-Changed-From-To: open->closed
State-Changed-By: martin@NetBSD.org
State-Changed-When: Fri, 30 May 2014 13:15:45 +0000
State-Changed-Why:
Patch applied, many thanks for the quick analysis
From: "Thomas Schmitt" <scdbackup@gmx.net>
To: gnats-bugs@NetBSD.org
Cc:
Subject: Re: kern/48852 CD9660 RockRidge: device files not properly handled
Date: Fri, 30 May 2014 15:44:37 +0200
The mentioned bad TF entries have been fixed already.
See youngest commit to makefs/cd9660/iso9660_rrip.c.
(Funnily i was the one who reported it to FreeBSD.)
I just downloaded and checked NetBSD-6.1.4-i386.iso.
No complaints any more.
>Unformatted:
(Contact us)
$NetBSD: query-full-pr,v 1.39 2013/11/01 18:47:49 spz Exp $
$NetBSD: gnats_config.sh,v 1.8 2006/05/07 09:23:38 tsutsui Exp $
Copyright © 1994-2007
The NetBSD Foundation, Inc. ALL RIGHTS RESERVED.
Home