Warning: DOMDocument::loadXML() [function.DOMDocument-loadXML]: PCDATA invalid Char value 1 in Entity, line: 142 in /srv/lkml.org/scripts/getmail.php on line 206
Warning: DOMDocument::loadXML() [function.DOMDocument-loadXML]: PCDATA invalid Char value 2 in Entity, line: 142 in /srv/lkml.org/scripts/getmail.php on line 206
Warning: XSLTProcessor::transformToXml() expects parameter 1 to be object, boolean given in /srv/lkml.org/scripts/getmail.php on line 209
This message generated a parse failure. Raw output follows here. Please use 'back' to navigate.
From devnull@lkml.org Thu Oct 16 00:54:59 2008
Delivery-date: Mon, 22 Jan 2007 09:56:33 +0000
Received: (majordomo@vger.kernel.org) by vger.kernel.org id S1750897AbXAVIyU (ORCPT ); Mon, 22 Jan 2007 03:54:20 -0500
Received: from ara.aytolacoruna.es ([195.55.102.196]:38232 "EHLO mx.aytolacoruna.es" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750849AbXAVIyT convert rfc822-to-8bit (ORCPT ); Mon, 22 Jan 2007 03:54:19 -0500
Received: from clandestino.aytolacoruna.es (clandestino2.aytolacoruna.es [195.55.102.222]) by mx.aytolacoruna.es (Postfix) with ESMTP id 12BC91BE492; Mon, 22 Jan 2007 09:54:00 +0100 (CET)
Received: by clandestino.aytolacoruna.es (Postfix, from userid 1000) id 86183185DB; Mon, 22 Jan 2007 09:54:00 +0100 (CET)
Date: Mon, 22 Jan 2007 09:54:00 +0100
From: Santiago Garcia Mantinan
To: Willy Tarreau
Cc: Grant Coady , dann frazier , linux-kernel@vger.kernel.org, debian-kernel@lists.debian.org
Subject: Re: problems with latest smbfs changes on 2.4.34 and security backports
Message-Id: <20070122085400.GA16302@clandestino.aytolacoruna.es>
References: <20070117100030.GA11251@clandestino.aytolacoruna.es> <20070117215519.GX24090@1wt.eu> <20070119010040.GR16053@colo> <20070120010544.GY26210@colo> <20070121230321.GC2480@1wt.eu>
Mime-Version: 1.0
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: QUOTED-PRINTABLE
In-Reply-To: <20070121230321.GC2480@1wt.eu>
User-Agent: Mutt/1.5.13 (2006-08-11)
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk
X-Mailing-List: linux-kernel@vger.kernel.org
Hi again!
I tried to replicate the problem at home during the weekend with my lap=
top,
but I couldn't get it to show links with previous kernels, so I guess I=
had
something different on my samba server or similar, I'm at the real mach=
ines
now so I have done the real tests and they look promising. I'm getting
completely different results than those of Grant, which seems really we=
ird.
I applied just this patch:
> > >--- kernel-source-2.4.27.orig/fs/smbfs/proc.c 2007-01-19 17:53:57.=
247695476 -0700
> > >+++ kernel-source-2.4.27/fs/smbfs/proc.c 2007-01-19 17:49:07.48016=
1733 -0700
> > >@@ -1997,7 +1997,7 @@
> > > fattr->f_mode =3D (server->mnt->dir_mode & (S_IRWXU | S_IRWXG |=
S_IRWXO)) | S_IFDIR;
> > > else if ( (server->mnt->flags & SMB_MOUNT_FMODE) &&
> > > !(S_ISDIR(fattr->f_mode)) )
> > >- fattr->f_mode =3D (server->mnt->file_mode & (S_IRWXU | S_IRWXG =
| S_IRWXO)) | S_IFREG;
> > >+ fattr->f_mode =3D (server->mnt->file_mode & (S_IRWXU | S_IRWXG =
| S_IRWXO)) | (fattr->f_mode & S_IFMT);
> > >=20
> > > }
To an unpatched 2.4.34, the client is an IBM NetworkStation 1000 (a Pow=
erPC
based thin client), and the server is a normal amd64 based PC running
2.6.19.1, both running Debian, the client runs Sarge and the Server Etc=
h.
I'm descriving this to see if differences on the architectures could be
causing the differences on behaviour between my tests and Grant's.
> > client running 2.4.34 with above patch, server is running 2.6.19.2 =
to=20
> > eliminate it from the problem space (hopefully ;) :
> > grant@sempro:/home/other$ uname -r
> > 2.4.34b
> > grant@sempro:/home/other$ ls -l
> > total 9
> > drwxr-xr-x 1 grant wheel 4096 2007-01-21 11:44 dir/
> > drwxr-xr-x 1 grant wheel 4096 2007-01-21 11:44 dirlink/
> > -rwxr-xr-x 1 grant wheel 15 2007-01-21 11:43 file*
> > -rwxr-xr-x 1 grant wheel 15 2007-01-21 11:43 filelink*
>=20
> It seems to me that there is a difference, because filelink now appea=
rs the
> same size as file. It's just as if we had hard links instead of symli=
nks.
Here is what I did, I mounted the remote filesystem on /mnt on my clien=
t,
the share on the server has a normal Debian Sarge PowerPC filesystem on=
it.
$ pwd
/mnt/usr
$ ls -l
total 0
drwxr-xr-x 1 root root 0 Feb 15 2005 X11R6
drwxr-xr-x 1 root root 0 Jan 16 2007 bin
drwxr-xr-x 1 root root 0 Jan 16 2007 doc
drwxr-xr-x 1 root root 0 Feb 10 2005 games
drwxr-xr-x 1 root root 0 Jan 16 2007 include
lrwxr-xr-x 1 root root 10 Jan 16 2007 info -> share/info
drwxr-xr-x 1 root root 0 Jan 16 2007 lib
drwxr-xr-x 1 root root 0 Feb 10 2005 local
drwxr-xr-x 1 root root 0 Jan 16 2007 sbin
drwxr-xr-x 1 root root 0 Jan 5 2006 share
drwxr-xr-x 1 root root 0 Dec 15 2004 src
$ ls -l info/
total 249856
-rwxr-xr-x 1 root root 150109 Jul 16 2004 coreutils.info.gz
-rwxr-xr-x 1 root root 1299 Jan 16 2007 dir
-rwxr-xr-x 1 root root 1299 Jan 16 2007 dir.old
-rwxr-xr-x 1 root root 28019 Mar 20 2005 find.info.gz
-rwxr-xr-x 1 root root 26136 Nov 22 2004 grep.info.gz
-rwxr-xr-x 1 root root 12914 Sep 16 2006 gzip.info.gz
-rwxr-xr-x 1 root root 12316 Sep 18 2005 ipc.info.gz
-rwxr-xr-x 1 root root 21432 Jan 23 2005 rl5userman.info.gz
-rwxr-xr-x 1 root root 26647 Dec 1 2004 sed.info.gz
-rwxr-xr-x 1 root root 123382 Dec 1 2006 tar.info.gz
-rwxr-xr-x 1 root root 54876 May 23 2005 wget.info.gz
$ cd ../bin
$ ls -l sh
lrwxr-xr-x 1 root root 4 Jan 16 2007 sh -> bash
$ dd if=3Dsh bs=3D1 count=3D6
=7FELF=01=026+0 records in
6+0 records out
6 bytes transferred in 0.001432 seconds (4190 bytes/sec)
As you can see I now can see the symbolic links perfectly and they work=
as
expected.
In fact, this patch is working so well that it poses a security risk, a=
s now
the devices on my /mnt/dev directory are not only seen as devices (like=
they
were seen on 2.4.33) but they also work (which didn't happen on 2.4.33)=
=2E
So... for me now the remote filesystem works as if it was a local
filesystem, without any difference of behaviour, not even on special fi=
les
like devices or whatever.
As I said before... this behaviour of having the remote device files wo=
rk...
seems a security problem and I don't think is desirable, other than tha=
t it
seems to work well on my PowerPC, I'll try to run the tests on a normal=
x86
client and report back.
Regards...
--=20
Santiago Garc=EDa Manti=F1=E1n
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel"=
in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/