Bug#352557: suggest

[Andrew Lee]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

I don't think we still need this package for Chinese desktop
environment, I suggest to remove this package from archive.

- -Andrew
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2 (GNU/Linux)

iD8DBQFD/ZE2nQYz4bYlCYURAjgXAJ48mY0j5XdcXZOwVoTlrTeFBJnUsgCeLhFY
ASTU9aOC39ZtcKwvL95yUJ0=
=8ycn
-END PGP SIGNATURE-



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#328209: [Vserver] Re: Bug#328209: [PATCH] Fix syscall number detection

[Andrew Lee]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

found 328209 0.30.204-5sarge2
tags +patch
thanks

Ola Lundqvist wrote:
 I'm aware of this problem. Not really sure that it should be considered
 grave but as we have a solution to it I do not really bother.

I considered it as grave beause util-vserver package in sarge is
unuseable on all non-i386 machines(It should be FTBFS, but it compiled
on the buildd).

The attached patch is a backported from Bertl's
delta-0.30.208-fix03-fix04-hack.diff to sarge, it fixs the syscall
number detection on no vserver patched kernel.

- -Andrew
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2 (GNU/Linux)

iD8DBQFDYelwnQYz4bYlCYURAuH3AKDV3WAX9jDVw2HkTxD/xXnl77JTcQCffzKz
rrqj2294Tjm48Jt2pJ8vIN8=
=AD3H
-END PGP SIGNATURE-
diff -urN util-vserver-0.30.204.orig/configure util-vserver-0.30.204/configure
--- util-vserver-0.30.204.orig/configure2005-02-16 07:14:42.0 
+0800
+++ util-vserver-0.30.204/configure 2005-10-28 16:42:17.166831216 +0800
@@ -23746,8 +23746,11 @@
 ac_compiler_gnu=$ac_cv_c_compiler_gnu
 
cat conftest.$ac_ext _ACEOF
-
+#if (ENSC_MARK == alternative)
+#include vserver-syscall-def.h
+#else
 #include asm/unistd.h
+#endif
 #ifdef __NR_vserver
 ensc_syscall_tmp_nr=__NR_vserver;
 ensc_syscall_tmp_src=ENSC_MARK
@@ -23757,6 +23760,8 @@
ensc_syscall_tmp_nr=
ensc_syscall_tmp_src=
test $ensc_syscall_tmp_nr || \
+   eval $($CPP $CPPFLAGS -D ENSC_MARK='alternative' -Ilib  
   conftest.c | $EGREP 
'^ensc_syscall_tmp_(nr=[1-9][0-9]*;|src=.*)$')   
+   test $ensc_syscall_tmp_nr || \
eval $($CPP $CPPFLAGS -D ENSC_MARK='glibc'  
   conftest.c | $EGREP 
'^ensc_syscall_tmp_(nr=[1-9][0-9]*;|src=.*)$')
test $ensc_syscall_tmp_nr || \
eval $($CPP $CPPFLAGS -D ENSC_MARK='kernel' -I 
$ensc_cv_path_kernelheaders conftest.c | $EGREP 
'^ensc_syscall_tmp_(nr=[1-9][0-9]*;|src=.*)$')
@@ -23878,7 +23883,7 @@
   echo $as_me: failed program was: 5
 sed 's/^/| /' conftest.$ac_ext 5
 
-ensc_cv_test_syscall=traditional
+ensc_cv_test_syscall=alternative
 fi
 rm -f conftest.err conftest.$ac_objext conftest.$ac_ext
 
diff -urN util-vserver-0.30.204.orig/lib/syscall-wrap.h 
util-vserver-0.30.204/lib/syscall-wrap.h
--- util-vserver-0.30.204.orig/lib/syscall-wrap.h   1970-01-01 
08:00:00.0 +0800
+++ util-vserver-0.30.204/lib/syscall-wrap.h2005-10-28 16:40:36.884076512 
+0800
@@ -0,0 +1,42 @@
+// $Id: syscall-wrap.h,v 1.2 2005/05/02 21:42:05 ensc Exp $--*- c -*--
+
+// Copyright (C) 2005 Enrico Scholz [EMAIL PROTECTED]
+//  
+// This program is free software; you can redistribute it and/or modify
+// it under the terms of the GNU General Public License as published by
+// the Free Software Foundation; version 2 of the License.
+//  
+// This program is distributed in the hope that it will be useful,
+// but WITHOUT ANY WARRANTY; without even the implied warranty of
+// MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
+// GNU General Public License for more details.
+//  
+// You should have received a copy of the GNU General Public License
+// along with this program; if not, write to the Free Software
+// Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
+
+
+#ifndef H_UTIL_VSERVER_LIB_SYSCALL_WRAP_H
+#define H_UTIL_VSERVER_LIB_SYSCALL_WRAP_H
+
+#ifdef ENSC_USE_ALTERNATIVE_SYSCALL_MACROS
+
+#  undef _syscall0
+#  undef _syscall1
+#  undef _syscall2
+#  undef _syscall3
+#  undef _syscall4
+#  undef _syscall5
+#  undef _syscall6
+#  undef _syscall7
+
+#  include syscall-alternative.h
+#  include vserver-syscall-def.h
+#else
+
+#  include sys/syscall.h
+#  include syscall.h
+#  include unistd.h
+#endif
+
+#endif //  H_UTIL_VSERVER_LIB_SYSCALL_WRAP_H
diff -urN util-vserver-0.30.204.orig/lib/vserver-internal.h 
util-vserver-0.30.204/lib/vserver-internal.h
--- util-vserver-0.30.204.orig/lib/vserver-internal.h   2004-09-23 
05:48:24.0 +0800
+++ util-vserver-0.30.204/lib/vserver-internal.h2005-10-28 
16:40:36.886076208 +0800
@@ -225,9 +225,7 @@
   return syscall(__NR_vserver, cmd, id, data);
 }
 #else
-inline static UNUSED ALWAYSINLINE
-_syscall3(int, vserver,
- uint32_t, cmd, uint32_t, id, void *, data)
+#include vserver-syscall-def.h
 #endif
 #endif
 
diff -urN util-vserver-0.30.204.orig/lib/vserver-syscall-def.h 
util-vserver-0.30.204/lib/vserver-syscall-def.h
--- util-vserver-0.30.204.orig/lib/vserver-syscall-def.h1970-01-01 
08:00:00.0 +0800
+++ util-vserver-0.30.204/lib/vserver-syscall-def.h 2005-10-28 
16:40:36.887076056 +0800
@@ -0,0 +1,48 @@
+
+#include stdint.h
+
+#include syscall.h
+
+#ifdefined(__alpha__)
+#define __NR_vserver   428
+#elif  defined(__arm__)
+#define __NR_vserver   313
+#elif  defined(__cris__)
+#define __NR_vserver   273
+#elif  defined(__frv__)

Bug#328209: util-vserver: Wrong vserver syscall on powerpc

[Andrew Lee]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

reopen #328209
severity #328209 grave
retitle #328209 util-vserver: built with wrong vserver syscall
thanks

Hi,

I found the util-vserver from sarge doesn't work on powerpc as well,
and it works after rebuilt on a patched vserver kernel.

My tests are on an ibook with a fresh installed sarge:
All tests use these scripts:
http://vserver.13thfloor.at/Stuff/SCRIPT/testme.sh
http://vserver.13thfloor.at/Stuff/SCRIPT/testfs.sh


#Test1
kernel: 2.6.8-16 (sarge)
vserver-patch: 1.9.5.3 (sarge)
util-vserver: 0.30.204-5sarge2 (sarge)

~# ./testme.sh
Linux-VServer Test [V0.13] Copyright (C) 2003-2005 H.Poetzl
chcontext: vc_new_s_context(): Function not implemented
chcontext failed!
chbind: vc_set_ipv4root(): Function not implemented
chbind failed!
Linux 2.6.8-16+vserver1.9.5.3 ppc/0.30.204/0.30.204 [Ea] (0)
VCI:  0001:0025 257 8376
- ---
~# vserver-info - SYSINFO
Versions:
   Kernel: 2.6.8-16+vserver1.9.5.3
   VS-API: ???
 util-vserver: 0.30.204; May 26 2005, 02:11:52

Features:
   CC: gcc, gcc (GCC) 3.3.5 (Debian 1:3.3.5-12)
  CXX: g++, g++ (GCC) 3.3.5 (Debian 1:3.3.5-12)
 CPPFLAGS: ''
   CFLAGS: '-Wall -g  -O2 -std=c99 -Wall -pedantic -W'
 CXXFLAGS: '-g -O2 -ansi -Wall -pedantic -W
- -fmessage-length=0'
   build/host:
powerpc-unknown-linux-gnu/powerpc-unknown-linux-gnu
 Use dietlibc: yes
   Build C++ programs: yes
   Build C99 programs: yes
   Available APIs: compat,v11,v13,fscompat,net,oldproc,olduts
ext2fs Source: e2fsprogs
syscall(2) invocation: fast
  vserver(2) syscall#: 273/default

Paths:
   prefix: /usr
sysconf-Directory: /etc
cfg-Directory: /etc/vservers
 initrd-Directory: $(sysconfdir)/init.d
   pkgstate-Directory: /var/run/vservers
Kernelheaders: /usr/include
  vserver-Rootdir: /var/lib/vservers

#Test2
Same kernel-image with test1, but with a rebuilt util-vserver.
kernel: 2.6.8-16 (sarge)
vserver-patch: 1.9.5.3 (sarge)
util-vserver: 0.30.204-5sarge2.local.0 (local rebuilt)


Linux-VServer Test [V0.13] Copyright (C) 2003-2005 H.Poetzl
chcontext is working.
chbind is working.
Linux 2.6.8-16+vserver1.9.5.3 ppc/0.30.204/0.30.204 [Ea] (0)
VCI:  0001:0025 257 8376
- ---
[000]# succeeded.
[001]# succeeded.
[011]# succeeded.
[031]# succeeded.
[101]# succeeded.
[102]# succeeded.
[201]# succeeded.
[202]# succeeded.
~# ./testme.sh -L
Linux-VServer Test [V0.13] Copyright (C) 2003-2005 H.Poetzl
chcontext is working.
chbind is working.
Linux 2.6.8-16+vserver1.9.5.3 ppc/0.30.204/0.30.204 [Ea] (0)
VCI:  0001:0025 257 8376
- ---
[000]# succeeded.
[001]# succeeded.
[011]# succeeded.
[031]# succeeded.
[101]# succeeded.
[102]# succeeded.
[201]# succeeded.
[202]# succeeded.
- ---
[L01]# succeeded.
[D01]# succeeded.
[L02]# succeeded.
[D02]# succeeded.
[L03]# succeeded.
[D03]# succeeded.
[L11]# succeeded.
[D11]# succeeded.
[L12]# succeeded.
[D12]# succeeded.
[L21]# succeeded.
[D21]# succeeded.
[L22]# succeeded.
[D22]# succeeded.

Prepare testfs.sh script for checks some filesystem functionality:

~# wget http://vserver.13thfloor.at/Stuff/SCRIPT/testfs.sh
~# chmod +x testfs.sh
~# dd bs=1024k count=1024 if=/dev/zero of=1gb.testfile
~# losetup /dev/loop0 1gb.testfile

Run the testfs.sh script for legacy mode and only test on ext3 filesystem:

~# ./testfs.sh -l -F ext3 -t -D /dev/loop0 -M /mnt
Linux-VServer FS Test [V0.10] Copyright (C) 2005 H.Poetzl
Linux 2.6.8-16+vserver1.9.5.3 ppc/0.30.204
VCI:  0001:0025 257 8376 (ugid24)
- ---
testing ext3 filesystem ...
[000]. xattr related tests ...
[101]. [102]. [103]* [104]* [106]. [108]. [109]*
[112]. [113]* [114]* [115]. [116]. [117]. [118]. [119]*
[121]* [122]* [123]* [124]* [199].

Lots of errors in legacy mode checks.

Let's run the testfs.sh script for new-style config and only test on ext3
filesystem:

~# ./testfs.sh -F ext3 -t -D /dev/loop0 -M /mnt
Linux-VServer FS Test [V0.10] Copyright (C) 2005 H.Poetzl
Linux 2.6.8-16+vserver1.9.5.3 ppc/0.30.204
VCI:  0001:0025 257 8376 (ugid24)
- ---
testing ext3 filesystem ...
[000]. xattr related tests ...
[101]. [102]. [103]. [104]. [106]. [108]. [109].
[112]. [113]. [114]. [115]. [116]. [117]. [118]. [119].
[121]. [122]. [123]. [124]. [199].

No error in new-style config, oh ye! :p

Let's see the correct vserver syscall:

~# vserver-info - SYSINFO
Versions:
   Kernel: 2.6.8-16+vserver1.9.5.3
   VS-API: 0x00010025
 util-vserver: 0.30.204; Oct 27 2005, 00:01:03

Features:
   CC: gcc, gcc (GCC) 3.3.5 (Debian 1:3.3.5-13)
  CXX: g++, g++ (GCC) 3.3.5 (Debian 1:3.3.5-13)
 CPPFLAGS: ''
   CFLAGS: '-Wall -g  -O2 -std=c99 -Wall -pedantic -W'
 CXXFLAGS: '-g -O2 -ansi -Wall -pedantic -W
- 

Bug#329090: util-vserver: barrier not working, but chroot escape does

[Andrew Lee]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Dear Micah,

Thank you for your tests, I have downloaded the testfs-0.11.sh and did
the similar tests as yours to help confirm the results.

 Test #1
 Using all debian sarge componants:
 kernel-source: 2.4.27-10 (debian sarge)
 util-vserver: 0.30-204-5sarge2 (debian sarge)
 kernel-patch: 1.9.5.3 (debian sarge)
 
 103, 104, 106, 109, 121, 122 all fail on ext2, not 114 or 124 as your
 tests show.
 
 Conclusion: either the fixes to testfs caused error 114 and 124 to go
 away, or you have a different kernel-source or kernel-patch applied.
 Either try again with testfs.sh-0.11 or install the latest sarge kernel
 source and kernel-patch-vserver as those versions are all that matter here.

I am using all deian sarge componats, all the same version as yours,
and then did the testfs.sh-0.11 by this way(I've setup a loopback file
on /dev/loop0 already), before start the testfs.sh-0.11, I confirmed the
barrier has proper setup(I also did this in my other tests later):
# ls -lda /var/lib/vservers
d-  8 root root 4096 Oct 13 15:37 /var/lib/vservers/
# showattr -d /var/lib/vservers/
- ---BU-- /var/lib/vservers/
# lsattr -d /var/lib/vservers
- ---t- /var/lib/vservers

# ./testfs.sh-0.11 -l -t -D /dev/loop0 -M /mnt
Linux-VServer FS Test [V0.10] Copyright (C) 2005 H.Poetzl
Linux 2.4.27-10vserver-confirm i686/0.30.204
VCI:  none   (unknown)
- ---
testing ext2 filesystem ...
[000]. xattr related tests ...
[101]. [102]. [103]* [104]* [106]* [108]. [109]*
[112]. [113]. [114]. [115]. [116]. [117]. [118]. [119].
[121]* [122]* [123]. [124]. [199].

- ---
testing ext3 filesystem ...
[000]. xattr related tests ...
[101]. [102]. [103]* [104]* [106]* [108]. [109]*
[112]. [113]. [114]. [115]. [116]. [117]. [118]. [119].
[121]* [122]* [123]. [124]. [199].

Same fails as you got, and I guess Bertl forgot to change the version in
the script, so the script is still showing [V0.10].

I also tested the exploit:

# ./rootesc
Exploit seems to work. =)
#
And then I can be able to access the host, for example, I can see the
vserver's config file on host:
# ls -ald /etc/vservers /var/lib/vservers/
drwxr-xr-x  4 root root 4096 Sep 22 14:10 /etc/vservers
d-  8 root root 4096 Oct 13 15:37 /var/lib/vservers/

 Test #2
 Using only debian sarge util-vserver:
 kernel-source: 2.4.31 (upstream)
 util-vserver: 0.30-204-5sarge2 (debian sarge)
 kernel-patch: 1.2.10 (upstream)
 
 
 103, 104, 106, 109, 121, 122 all fail on ext2, the same as failed using
 all debian sarge componants in test #1.
 
 Conclusion: based on the results from this test, and the previous, it is
 clear that the debian kernel source and the debian kernel patch dont
 make a difference here

Same here, I am using the vanilla kernel 2.4.31(from kernel.org)
vserver patch 1.2.10 (upstream)
util-vserver: 0.30-204-5sarge2 (debian sarge)

./testfs.sh-0.11 -l -t -D /dev/loop0 -M /mnt
Linux-VServer FS Test [V0.10] Copyright (C) 2005 H.Poetzl
Linux 2.4.31-vs1.2.10 i686/0.30.204
VCI:  none   (unknown)
- ---
testing ext2 filesystem ...
[000]. xattr related tests ...
[101]. [102]. [103]* [104]* [106]* [108]. [109]*
[112]. [113]. [114]. [115]. [116]. [117]. [118]. [119].
[121]* [122]* [123]. [124]. [199].

- ---
testing ext3 filesystem ...
[000]. xattr related tests ...
[101]. [102]. [103]* [104]* [106]* [108]. [109]*
[112]. [113]. [114]. [115]. [116]. [117]. [118]. [119].
[121]* [122]* [123]. [124]. [199].

Same result as you got, seems the testfs #1 and #2 shows no difference,
but the exploit works on #1's setup, not on #2.

# ./rootesc
cd ..: Permission denied
chmod: Operation not permitted
cd ..: Permission denied
chmod: Operation not permitted
(alternating a few times)
then the false:
Exploit seems to work. =)
(because it always shows this line, actually it failed, but nobody
bothered to fix up the exploit bug)

 Test #3
 Using debian sarge componants with upstream util-vserver:
 kernel-source: 2.4.27-10 (debian sarge)
 util-vserver: 0.30-208+fix03 (upstream)
 kernel-patch: 1.9.5.3 (debian sarge)
 
 Only test 106 fails... Not 104, 114, 122 or 124.
 
 Conclusion: either the fixes to testfs caused 104, 114, 122, 124 to go
 away or you have a different kernel-source or kernel-patch applied, try
 with testfs.sh-0.11 to see, or just try with a current sarge kernel and
 patch since that is all that matters here.

In your test #3, you used the 0.30-208+fix03 from upstream, and I am
using the one from sid, let's see any difference:
I upgrade the util-vserver from sid on sarge(libc6 libc6-dev locales are
also to be upgraded). These are the messages I got:
Setting up util-vserver (0.30.208-3) ...
Installing new version of config file /etc/init.d/rebootmgr ...
Installing new version of config file /etc/init.d/vprocunhide ...
Installing new version of config file /etc/init.d/vservers-legacy ...
/var/lib/vservers: Operation not permitted

For the error message, I don't know what is wrong in postinst script,
but after I looked at the 

Bug#329090: util-vserver: barrier not working, but chroot escape does

[Andrew Lee]

Hi Ola,在 2005/10/3 上午 1:54 時，Ola Lundqvist 寫到：How did you tested and found what kind of security problem?I assume you found you couldn't pass the test 109,121 of testfs.sh  script, right? Actually I run the rootesc program and saw that it was possible toescape.I think the rootesc program is only working for the bug in 2.4 kernel patches in Debian, for other fails in testfs.sh, I guess probably needs other exploit.I have upgraded to 0.30.208-2, I still got the same fails on i386,  but no errors on powerpc after I rebuilt the util-vserver package  from source. Ahh now I see. Missed that you used different architectures in yourtesting.Yes, that's why I have another powerpc related bug report.Sorry for the confusion, I will help to test on i386 and powerpc for you.I wonder why it do not fail after your rebuild. Maybe it passonly if I compile on a vserver patched system...Could you please confirm this?Maybe, I should recompile the kernel patch+tools on i386 with a vserver 2.0 patched system, cause I got fails on 2.6.12 and util-vserver 0.30.208-2 from sid still, but all pass with same version from sid on powerpc after a rebuild of util-vserver package.-Andrew

Bug#329090: util-vserver: barrier not working, but chroot escape does

[Andrew Lee]

Hi Ola,

在 2005/10/3 上午 3:39 時，Ola Lundqvist 寫到：


Now I have run the entire test suite...

zircone:/srv/vservers/labradorit/root# ./testfs.sh -l -t -D /dev/ 
loop4 -M /mnt/t

Linux-VServer FS Test [V0.09] Copyright (C) 2005 H.Poetzl
Linux 2.4.27-mppe+ctx+vlan-686-smp i686/0.30.204
VCI:  none   (unknown)


Sorry, it's my fault again, I didn't mention all the steps.
You should make a loopback file and run losetup /dev/loop4  
loopbackfile before run the testfs.sh script.
The VCI shouldn't be none if you have setup /dev/loop4 correctly, I  
did same thing and got same errors when I forgot to setup the /dev/ 
loop4 after a reboot.


Here is what I did for create a loopback file and the run losetup:
# dd bs=1024k count=1024 if=/dev/zero of=1gb.testfile
# losetup /dev/loop4 1gb.testfs
Note: I have other loopback files running on /dev/loop{0,1,2,3}  
already, so I use /dev/loop4 in my case.


Very sorry for made your confused. Could you please test it again?
I think the testfs.sh script will give you information of VCI and do  
the real checks on each task after you setup /dev/loop4 correctly.
If the testfs.sh give you fails on 109 and 121, that can confirm this  
is bug.
For other fails, you may ask Bertl, cause upstream author knows much  
more than me, also much better than I forward your questions to him. :)


I suggest to put or mention these test tasks in util-vserver package  
for our users to make sure the vserver patch+tools work properly.
Should I create another report as wistlist or only mentioned here is  
enough?


Regards,

-Andrew

Bug#329090: util-vserver: barrier not working, but chroot escape does

[Andrew Lee]

在 2005/10/2 上午 5:52 時，Ola Lundqvist 寫到：

I have now tested on one of my systems and that I have a security  
problem there.
On the other system (2.4.26 + grsec) the problem do not exist. So  
I'm not

sure if I can confim or deny this.


How did you tested and found what kind of security problem?
I assume you found you couldn't pass the test 109,121 of testfs.sh  
script, right?


Let me quote the explanation from upstream:
quote
23:51  Bertl 109 and 121 indicate that the barrier is not working ...
23:52  Bertl - minor issue with namespaces, major chroot security  
issue with

   legacy guests
/quote


It would be really good if you could install the sarge util-vserver  
on the
sid kernel-patch-vserver + linux-source-2.6.12 system to see if  
this is a

problem with util-vserver or with the kernel patches.



I tested that several days ago, I was upgraded kernel on my system  
first and then I got the same fails from the test of testfs.sh script  
again.
I have upgraded to 0.30.208-2, I still got the same fails on i386,  
but no errors on powerpc after I rebuilt the util-vserver package  
from source.


Here is how I did the test and what I got on an i386 machine:
# testfs.sh -l -t -D /dev/loop4 -M /mnt
Linux-VServer FS Test [V0.09] Copyright (C) 2005 H.Poetzl
Linux 2.6.12-6vs2-p4smp i686/0.30.208
VCI:  0002:0001 273 0376 (ugid24)
---
testing ext2 filesystem ...
[000]. xattr related tests ...
[101]. [102]. [103]* [104]* [106]. [108]. [109]*
[112]. [113]* [114]* [115]. [116]. [117]. [118]. [119]*
[121]* [122]* [123]* [124]* [199].
---
testing ext3 filesystem ...
[000]. xattr related tests ...
[101]. [102]. [103]* [104]* [106]. [108]. [109]*
[112]. [113]* [114]* [115]. [116]. [117]. [118]. [119]*
[121]* [122]* [123]* [124]* [199].
---
testing xfs filesystem ...
[000]* (xfs format failed)
---
testing reiser filesystem ...
[000]* (reiser format failed)
---
testing jfs filesystem ...
[000]* (jfs format failed)

-Andrew

Bug#328209: util-vserver: Does not work on powerpc

[Andrew Lee]

在 2005/9/30 上午 4:03 時，Micah 寫到：

 This sounds like a mismatched toolchain problem. I had this same  
problem
 when I had a kernel installed that was compiled with an older  
version of
 gcc, and then installed util-vserver_0.30.208-2 which had been  
compiled

 with the newer gcc4.0.

Does that means the buildd used mismatched toolchain to built the  
binary?

Cause the binary doesn't work for me.

 What kernel revision are you running and what vserver patch? What gcc
 did you use to compile your kernel? It looks like when you recompiled
 util-vserver with the gcc you have installed it started to work, this
 says to me that there is something out of date there.

The kernel version I am running is 2.6.12 which compiled by kernel- 
package with linux-source-2.6.12-6 and kernel-patch-vserver 2.0 from  
sid, and dmesg told me the version of gcc I did use to compiled is  
(gcc version 4.0.2 20050821 (prerelease) (Debian 4.0.1-6)).


-Andrew

Bug#329087: kernel-patch-vserver: be able to do chroot escape

[Andrew Lee]

Dear Micah,

Thank you for your replies, I merged the three replies in one here  
for you. :)


在 2005/9/30 上午 5:36 時，Micah 寫到：


Please tell me how you run this script and what failures you get, also
this is a destructive test, correct?


The test require a loopback file or an empty partition, I did use  
lookback file which created by:

# dd bs=1024k count=1024 if=/dev/zero of=1gb.testfile
And then
# losetup /dev/loop4 1gb.testfile
# ./testfs.sh -l -t -D /dev/loop4 -M /mnt



# showattr -d /var/lib/vservers//..
---BU-- /var/lib/vservers//..



This is not what I get on my i386 system:

# showattr -d /var/lib/vservers//..
- ---bui- /big/vservers//..


Yes, I assume you did the test on 2.6 kernel, cause I had got that  
with a test on 2.6 kernel.
My tested report was on a 2.4 kernel, so that explains the showattr  
shows different on 2.4 and 2.6.



# lsattr -d /var/lib/vservers//..
---t- /var/lib/vservers//..



Also I do not get this on my system:
# lsattr -d /var/lib/vservers//..
- - /big/vservers//..


Bertl told me to use chattr +t to enable that before the tests.


Please tell me what architecture you are running, what kernel version
you are running, which kernel patch you are running and how you  
applied
and compiled the kernel. Additionally, did you setup the chroot  
barrier

properly?


I found this on i386 architecture, the version of kernel is 2.4.27  
which made by kernel-package with kernel-source-2.4.27-10 and kernel- 
patches/diffs/vserver/patch-2.4.27-9-vs1.2.10-2.diff.gz
I was following Bertl's steps to setup the chroot barrier before the  
tests:

quote
19:52  Bertl setattr --barrier /vservers//..
setattr --barrier /vservers//..
19:53  Bertl ls -lad /vservers//..
19:53  Bertl d-   11 root root 1024 Jul  7 16:48
   /vservers//..
19:53  Bertl showattr -d /vservers//..
19:53  Bertl ---BU-- /vservers//..
19:53  Bertl lsattr -d /vservers//..
19:53  Bertl ---t- /vservers//..
19:53  Bertl (on 2.4 it is important that you verify the following)
19:54  Bertl the directory permissions _are_ 000, the barrier 'B' and
iunlink
   'U' is reported, the 't' flag shows up
19:54  Bertl ('U' and 't' are connected on 2.4)
/quote
Above are Bertl's steps, the only thing different on my test was my  
vserver root dir is /var/lib/vservers(which is the default in Debian).



I think you may have set something up incorrectly, or perhaps the
util-vserver tools did not set the chroot barrier properly.


I think the util-vserver tools did not set the chroot barrier  
properly might be possible, but I did the chroot barrier again before  
the tests, so it would not be a barrier setup problem.


However, I am *not* able to access the host, I cannot read /etc/ 
shadow,

nor can I create /test.txt in the host.


I think because you tested it on 2.6 kernel, if you test it on 2.4  
kernel will reproduce the problem I reported.


I am going to try and speak with Bertl about this to try and narrow  
down

the issue.


Bertl asked me to file this bug, cause after I report my test results  
to him, he found it was a two years old issue and his fixed it long  
time ago.
He also asked me to try 2.4.31 with the patch from upstream, and then  
I confirmed the exploit doesn't work with upstream's patch.





# showattr -d /big/vservers//..
- ---Bui- /big/vservers//..

Which means that the barrier is set.


Yes, on 2.6 kernel must displays like that.

Also, the rootesc.c code is dumb and says the exploit works all the  
time

when it doesnt, on any 2.6 setup with namespaces its going to say that
when it isn't actually successful.


Yes, that is a bug in the exploit, but who cares to fix exploit's  
bug? :p
Very sorry for the confusion, I didn't gave enough information that  
the exploit is only working on sarge's kernel-source-2.4.27 with the  
a patch from kernel-patch-vserver.
I found the kernel-source-2.6.8+kernel-patch-vserver in sarge doesn't  
pass the test of testfs.sh script as well, Bertl mentioned that maybe  
some security releate issue but he didn't give me a exploit for that.


-Andrew

Bug#329090: util-vserver: barrier not working, but chroot escape does

[Andrew Lee]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Ola Lundqvist wrote:

 I do not have access to a 2.6 kernel patched with vserver but I
 can check on a patched 2.4 kernel with old style patch.

Okay, I have a machine running 2.6 kernel patched with vserver 2.0, so
what can I help you on 2.6 kernel patched with vserver?

I have tried and successed escape from vserver's guest by using the
expolits[2], and failed on the test of testfs.sh script[1], could you
please do both tests on your 2.4 kernel patched with old style patch to
confirm the is really a security problem.

[1] http://vserver.13thfloor.at/Stuff/SCRIPT/testfs.sh-0.09
[2] http://vserver.13thfloor.at/Stuff/rootesc.c

Regards,

- -Andrew

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2 (GNU/Linux)

iD8DBQFDOjx8nQYz4bYlCYURArJNAKC+Z05GtpBdyrvA4g8t8GwM0hbq/wCgjA9N
a4LSt5deo0o/oFLB1Ta2hnU=
=AX4d
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#328209: To buildd admin: requests for some files of util-vserver on powerpc.

[Andrew Lee]

Dear buildd admin(s),

I wrote this email for request more files for inverstage why buildd 
built a binary with wrong syscall number in buildd log which made the 
binary doesn't work at all on powerpc still.


Could you please send me the the config.log and also 
/usr/include/{linux,asm} as a tarball would be the best.


Thank you for your time.

-Andrew


--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#328209: To buildd admin: requests for some files of util-vserver on powerpc.

[Andrew Lee]

Sorry, I forgot to mention the files from builds of util-vserver package.

-Andrew

Andrew Lee 提到:

Dear buildd admin(s),

I wrote this email for request more files for inverstage why buildd 
built a binary with wrong syscall number in buildd log which made the 
binary doesn't work at all on powerpc still.


Could you please send me the the config.log and also 
/usr/include/{linux,asm} as a tarball would be the best.


Thank you for your time.

-Andrew

Bug#274201: irssi-text: Displays incorrect Chinese characters on input bar.

[Andrew Lee]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi David and Timothy,

I have tested irssi-text 0.8.9-6 on en_US.UTF-8 with screen, it works
fine for me.
And I found the problem might be the screen was not started in
en_US.UTF-8 locale, cause if the screen was started in en_US.UTF-8,
you don't need -U option to convert the screen output to UTF8.

Here is what I did in my test:

$ export LC_ALL=en_US.UTF-8
$ locale
LANG=POSIX
LC_CTYPE=en_US.UTF-8
LC_NUMERIC=en_US.UTF-8
LC_TIME=en_US.UTF-8
LC_COLLATE=en_US.UTF-8
LC_MONETARY=en_US.UTF-8
LC_MESSAGES=en_US.UTF-8
LC_PAPER=en_US.UTF-8
LC_NAME=en_US.UTF-8
LC_ADDRESS=en_US.UTF-8
LC_TELEPHONE=en_US.UTF-8
LC_MEASUREMENT=en_US.UTF-8
LC_IDENTIFICATION=en_US.UTF-8
LC_ALL=en_US.UTF-8
$ screen
And then let's make sure the enviroment is en_US.UTF-8
$ locale
LANG=POSIX
LC_CTYPE=en_US.UTF-8
LC_NUMERIC=en_US.UTF-8
LC_TIME=en_US.UTF-8
LC_COLLATE=en_US.UTF-8
LC_MONETARY=en_US.UTF-8
LC_MESSAGES=en_US.UTF-8
LC_PAPER=en_US.UTF-8
LC_NAME=en_US.UTF-8
LC_ADDRESS=en_US.UTF-8
LC_TELEPHONE=en_US.UTF-8
LC_MEASUREMENT=en_US.UTF-8
LC_IDENTIFICATION=en_US.UTF-8
LC_ALL=en_US.UTF-8
Okay, and now use irssi and type some non-ASCII stuffs.
And then try detaching and re-attaching the screen session by command
$ screen -r
All the characters are still display correctly.

- -Andrew
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2 (GNU/Linux)

iD8DBQFDORUnnQYz4bYlCYURAs4fAJ9beHwNdWdvcNREKE4+7jFGA2UKQgCg1I2w
VJpgt98gQYDUSZhN+9yUdRs=
=TgLW
-END PGP SIGNATURE-




-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#328209: util-vserver: Does not work on powerpc

[Andrew Lee]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Dear Ola,

Ola Lundqvist 提到:

The error message:
vc_new_s_context(): Function not implemented
 
 
 When runnign what command?

I found the error message after I run newvserver script.
And vserver vserver start reports that as well.

The problem has been solved on my ibook by unapply the fix01 diff and
use the fix02 diff instead.

You can get the fix02 diff on http://www.13thfloor.at/vserver/s_rel26/v2.0/

- -Andrew


-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2 (GNU/Linux)

iD8DBQFDN4YonQYz4bYlCYURAjYfAJ4hh9RbGiEDfPs+J3mEdIACuhJwrwCgzrJd
SRfktXDoNno3tS6jLCGcqog=
=Xd1k
-END PGP SIGNATURE-

Bug#328209: util-vserver: Does not work on powerpc

[Andrew Lee]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Dear Ola,

Thanks for the upload. I have found util-vserver 0.30.208-2 on
incoming.d.o, I will give it a try on my powerpc right now.

- -Andrew
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2 (GNU/Linux)

iD8DBQFDN4banQYz4bYlCYURApaVAKCIaeBWd+UsGVlx+jTfNhsRdsJ/LwCfat3p
7EcusX7KO5gvH4krhq2hxLc=
=EjO8
-END PGP SIGNATURE-



-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#329090: util-vserver: barrier not working, but chroot escape does

[Andrew Lee]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Ola Lundqvist wrote:
 Is util-vserver from sid necessary for this or is it just the kernel
 patch that is needed to fix it?

Not sure yet, I have successed passed the test of testfs.sh script on
powerpc with util-vserver from sid(applied the fix02 patch myself) and
linux-source-2.6.12-6+kernel-patch-vserver-2.0, but never successed on i386.

Could you please run the same test as I did on your side to see if you
can reproduce the error or not?

The upstream author said the test the 109 verifies that barrier was
removed correctly, while the test 121 checks that it was set correctly.
So I think these are potential security holes in current version of
util-vserver in Debian, not only in sarge.

- -Andrew
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2 (GNU/Linux)

iD8DBQFDN4qHnQYz4bYlCYURAro0AKDVTVqeNMxqZGFdqubzRYdj0XGeJgCfbTov
RCtQEjqiYqWhtw/jed0olFg=
=kZ9k
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#328209: util-vserver: Does not work on powerpc

[Andrew Lee]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Andrew Lee wrote:
 Dear Ola,
 
 Thanks for the upload. I have found util-vserver 0.30.208-2 on
 incoming.d.o, I will give it a try on my powerpc right now.
 
 -Andrew

Very unfortunately, I tested failed with this:
http://incoming.debian.org/util-vserver_0.30.208-2_powerpc.deb

The vserver syscall#: changed to 273/default

So made all tools in the util-vserver couldn't work, eg:
vserver-stat
vs_new_s_context():Funtion not implemented
and even this doesn't work:
showattr -d /var/lib/vservers
vc_get_iattr():Function not implemented

I will try to build util-vserver from source to see if I can reproduce this.

- -Andrew
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.2 (GNU/Linux)

iD8DBQFDN5YWnQYz4bYlCYURApFWAKDeZUesIqbivSX2L6J2VJhRozUdRQCguLWc
1a0b+G8fvgS7CrI8iG/vEs8=
=jKV0
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#329087: kernel-patch-vserver: be able to do chroot escape

[Andrew Lee]

Package: kernel-patch-vserver
Severity: critical
Tags: sarge
Justification: root security hole

Dear maintainer(s),

I found the kernel-patch-vserver and util-vserver in sarge can not pass
the testfs.sh script[1] which provide by upstream author. After some more
tests, upstream author discoveryed this is a security hole.

Here is what I did in my test:
# ls -lda /var/lib/vservers//..
d-  8 root root 4096 Sep 19 19:46 /var/lib/vservers//../
# showattr -d /var/lib/vservers//..
---BU-- /var/lib/vservers//..
# lsattr -d /var/lib/vservers//..
---t- /var/lib/vservers//..

ssh into a guest and then starting the root exploit[2] inside a guest now
gives: Exploit seems to work. =)

And then I can be able to access the host, can be able to read /etc/shadow
and can be able to create /test.txt in the host.

[1] http://vserver.13thfloor.at/Stuff/SCRIPT/testfs.sh-0.09
[2] http://vserver.13thfloor.at/Stuff/rootesc.c

-- System Information:
Debian Release: 3.1
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.4.27-10vserver
Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1)


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#329090: util-vserver: barrier not working, but chroot escape does

[Andrew Lee]

Package: util-vserver
Version: 0.30.204-5sarge2
Severity: critical
Tags: sarge
Justification: root security hole

Dear Ola,

I found the util-vserver in sarge can not pass the test 109 and 121 of 
testfs.sh script[1] which provide by upstream author. After more tests, 
upstream author discoveried this is a security hole.

109 verifies that barrier was removed correctly, while 121 checks that
it was set correctly.

This bug is kernel-patch-vserver related, I have filed a bug to
kernel-patch-vserver that you may have a look.

Here is what I did in my tests:
# dd bs=1024k count=1024 if=/dev/zero of=1gb.test
# losetup /dev/loop4 ./1gb.test
# ./testfs.sh -l -t -D /dev/loop4 -M /mnt

[1] http://vserver.13thfloor.at/Stuff/SCRIPT/testfs.sh-0.09

PS. I confirmed the kernel-patch-vserver + linux-source-2.6.12 + 
util-vserver in sid are passed the test of testfs.sh

-- System Information:
Debian Release: 3.1
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.4.27-10vserver
Locale: LANG=en_US, LC_CTYPE=en_US (charmap=ISO-8859-1)

Versions of packages util-vserver depends on:
ii  iproute 20041019-3   Professional tools to control the 
ii  libc6   2.3.2.ds1-22 GNU C Library: Shared libraries an
ii  libgcc1 1:3.4.3-13   GCC support library
ii  libstdc++5  1:3.3.5-13   The GNU Standard C++ Library v3
ii  net-tools   1.60-10  The NET-3 networking toolkit

util-vserver recommends no packages.

-- no debconf information


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#328209: util-vserver: Does not work on powerpc

[Andrew Lee]

Package: util-vserver
Version: 0.30.208-1
Severity: important

Hi Ola,

I found util-vserver does not work on my ibook.

The error message:
vc_new_s_context(): Function not implemented

Running kernel is vserver2 patched:
$ ls -ld /proc/virtual
dr-xr-xr-x  2 root root 0 Sep 14 14:35 /proc/virtual
$ dpkg -l|grep kernel-patch
ii  kernel-patch-vserver   2.0 context 
switching virtual private servers -

Output of vserver-info - SYSINFO:
Versions:
   Kernel: 2.6.12-2vs2
   VS-API: ???
 util-vserver: 0.30.208; Aug 18 2005, 11:17:44

Features:
   CC: gcc, gcc (GCC) 4.0.2 20050806 (prerelease) (Debian 
4.0.1-4)
  CXX: g++, g++ (GCC) 4.0.2 20050806 (prerelease) (Debian 
4.0.1-4)
 CPPFLAGS: ''
   CFLAGS: '-Wall -g  -O2 -std=c99 -Wall -pedantic -W 
-funit-at-a-time'
 CXXFLAGS: '-g -O2 -ansi -Wall -pedantic -W -fmessage-length=0 
-funit-at-a-time'
   build/host: powerpc-unknown-linux-gnu/powerpc-unknown-linux-gnu
 Use dietlibc: yes
   Build C++ programs: yes
   Build C99 programs: yes
   Available APIs: compat,v11,v13,fscompat,net,oldproc,olduts
ext2fs Source: e2fsprogs
syscall(2) invocation: alternative
  vserver(2) syscall#: 273/default

Paths:
   prefix: /usr
sysconf-Directory: /etc
cfg-Directory: /etc/vservers
 initrd-Directory: $(sysconfdir)/init.d
   pkgstate-Directory: /var/run/vservers
Kernelheaders: /usr/include
  vserver-Rootdir: /var/lib/vservers

I have asked this issue on #vserver channel, they ask me to file this 
bug and told me to try the one from the 13thfloor pages with the fix02.


-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: powerpc (ppc)
Shell:  /bin/sh linked to /bin/dash
Kernel: Linux 2.6.12-2vs2
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)

Versions of packages util-vserver depends on:
ii  iproute   20041019-3 Professional tools to control the 
ii  libc6 2.3.5-6GNU C Library: Shared libraries an
ii  net-tools 1.60-15The NET-3 networking toolkit

Versions of packages util-vserver recommends:
ii  binutils 2.16.1cvs20050902-1 The GNU assembler, linker and bina
ii  make 3.80-11 The GNU version of the make util

-- no debconf information


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#328222: im-switch breaks m17n-env

[Andrew Lee]

Package: im-switch
Version: 1.2
Severity: normal

Dear maintainer,

Scim with m17n-env used to work fine on my system until I upgrade
scim-anthy which depends on im-switch. Seems im-switch breaks m17n-env.
And I tried to follow up the steps which mentioned by README.Debian file,
but im-switch complain about my locale is not ja_JP.

Version of scim-anthy package:
ii  scim-anthy0.6.1-3 SCIM IMEngin

-- System Information:
Debian Release: testing/unstable
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: i386 (i686)
Shell:  /bin/sh linked to /bin/dash
Kernel: Linux 2.6.12-2vserver
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)

im-switch depends on no packages.

Versions of packages im-switch recommends:
ii  libapt-pkg-perl   0.1.17 Perl interface to libapt-pkg
ii  x11-common [xfree86-commo 6.8.2.dfsg.1-7 X Window System (X.Org) infrastruc
ii  xfree86-common6.8.2.dfsg.1-7 X Window System infrastructure tra

-- no debconf information


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#319856: newvserver script needs /etc/vservers/util-vserver-vars

[Andrew Lee]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi Lundqvist,

Ola Lundqvist wrote:
 If you want to have better features you have to wait until I have uploaded
 a fixed version of vserver-debiantools to unstable or you have to upgrade
 both vserver-debiantools and util-vserver to the ones in unstable. It 
 can be a bit problematic. Expect a fix for that in the next few days.

I have tested the new vserver-debiantools in sid with kernel-2.6.12 +
vserver2 patch, it act as new method without the warnnig/error messages,
thank you very much.

ii  kernel-image-2.6.12-2vserver10.00.Custom
ii  util-vserver0.30.208-1
ii  vserver-debiantools 0.2.3

 Legacy mode is what is expected in sarge. The other method was not
 tested enough to be allowed to go into stable.

But Legacy mode is not working well in sarge with linux 2.6.8.
I think a lot of warning and error messages are confusing our users and
myself, I hope at least mention this clearly in documents?

 This should not be a problem, but if you want to use the new
 method you have to use the new method.

I am using the new method in sid now, but there are lots of our users
would choose sarge for vserver and I think this is also an important
feature in sarge as well. Shall we support them by providing backports?

I have seem you have a pkg-vserver project on alioth.d.o, maybe there is
a good place to provide the backports, documentations, and I would like
to help if you don't mind.

PS. Unfortunately, seems the documentations are not very good in
util-vserver package and linux-vserver.org site, I still can't find
information for the configure files of new method.

- -Andrew
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFDE/vNnQYz4bYlCYURAn+WAKCdrnU9xFRZTH4ss1l+nsnqAPq/bgCgkRiT
BHEKbXspt6e9opA7TkepOWo=
=ZPTl
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#319856: newvserver script needs /etc/vservers/util-vserver-vars

[Andrew Lee]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hi Ola,


 # ls /etc/init.d/rebootmgr -l
 -rwxr-xr-x  1 root root 1421 May 25 04:22 /etc/init.d/rebootmgr
 
 It exist in all of my other machines too.
 
 
 Interesting. I have to check. It may be so that it still exist in sarge
 but has been removed from sid. It is possible.

Yes, it's still in sarge:
# dpkg -l util-vserver
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Installed/Config-files/Unpacked/Failed-config/Half-installed
|/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err:
uppercase=bad)
||/ Name   VersionDescription
+++-==-==-
ii  util-vserver   0.30.204-5sarg tools for Virtual private servers and
contex

# dpkg -L util-vserver|grep rebootmgr
/etc/init.d/rebootmgr
/usr/lib/util-vserver/legacy/rebootmgr
/usr/share/man/man8/rebootmgr.8.gz


 True, does any better way that other package maintainers do?
 
 Either make sure it get to unstable/testing or if it is really serious
 to stable. If we can debug this further and make good fix for it it
 may be possible to get it to stable as well.

Seems I should test it in testing an unstable, all my vserver machine
are running sarge.

 Is this bug big enough for to put an fix into stable release?
 
 
 Possibly. But first we have to determine the exact cause of the failure.

# dpkg -l vserver-debiantools
Desired=Unknown/Install/Remove/Purge/Hold
| Status=Not/Installed/Config-files/Unpacked/Failed-config/Half-installed
|/ Err?=(none)/Hold/Reinst-required/X=both-problems (Status,Err:
uppercase=bad)
||/ Name   VersionDescription
+++-==-==-
ii  vserver-debian 0.1.10 Tools to manage debian virtual servers

# grep util-vserver-vars /usr/sbin/newvserver
if [ -r /etc/vservers/util-vserver-vars ] ; then
. /etc/vservers/util-vserver-vars

 
 Because the file util-vserver-vars should NOT be in /etc... It was
 removed from there becuase it is changed to frequently (on every upgrade 
 actually)
 and therefor it is not suitable to have there.
 
 I'll see if I can reproduce it at my server, but if you have time to
 debug it further that would be really great!

I guess I found the problem but I am not sure, because not enough
information in the README.Debian to told me what should vserver works
like? I guess legacy method is not you expected.

All of my vserver are still running in lagacy method, I made them by
newvserver script after I copied the util-vserver-vars to /etc/vservers.

- -Andrew
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFC7a+RnQYz4bYlCYURAmwTAJ9qgSsHg6Jssm2MICxd0i6Y3+yaEwCeMLm1
6GYRJySsJFJr4BdXYAWyClo=
=Lqo0
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#319856: newvserver script needs /etc/vservers/util-vserver-vars

[Andrew Lee]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Ola Lundqvist wrote:


I actually do not think this is a problem. The util-vserver-vars file
exist in /usr/lib/util-vserver (as far as i remember) and it
can be used for building.

To determine the exact cause of this error. I need more information,
i.e. error output and probably some help with debugging.

Ok, these are the outputs:
- --
# newvserver --hostname dns --domain linux.org.tw --ip 10.0.0.5 --mirror
http://debian.nctu.edu.tw/debian/

[...skip these are normal]

Setting up base-config (2.53.10) ...

I: Base system installed successfully.
umount: /vservers/dns/dev/pts: not mounted
umount: /vservers/dns/dev/shm: not mounted
umount: /vservers/dns/proc/bus/usb: not mounted
WARNING: can not find configuration, assuming legacy method
No directory for this vserver: /etc/vservers/.defaults/vdirbase/dns
WARNING: can not find configuration, assuming legacy method
No directory for this vserver: /etc/vservers/.defaults/vdirbase/dns
WARNING: can not find configuration, assuming legacy method
No directory for this vserver: /etc/vservers/.defaults/vdirbase/dns
Restarting rebootmgr.
Stopping the reboot manager
Starting the reboot manager

You should now adjust /etc/vservers/dns.conf to suit your needs,
or else just go ahead and type `vserver dns start' to start
your new virtual server.  debian/rules!
- --- end 

It finished with no base-config dailog screen, and it installed vserver
into /vservers.
But it will be fine if I copy util-vserver-vars into /etc/vservers, it
installed into correct place and the base-config dailog screen will show
up for asking timezone, set password, adduser...etc just after a copy. :-)


It can be that you have a symlink that point to wrong location
maybe.

I think the symlink are correct.

# ls -l /etc/vservers/.defaults/
total 8
drwxr-xr-x  2 root root 4096 May 25 04:22 apps
drwxr-xr-x  2 root root 4096 May 25 04:22 files
lrwxrwxrwx  1 root root   21 Jul 25 15:09 run.rev - /var/run/vservers.rev
lrwxrwxrwx  1 root root   17 Jul 25 15:09 vdirbase - /var/lib/vservers


Did you a fresh install of util-vserver, or was it an upgrade from
older version in sarge before it entered testing.

I install util-vserver on a fresh installed sarge 3.1 r0a.
And it's no problem on my another machine which was upgrade from older
version in sarge before it entered testing cause the
/etc/vservers/util-vserver-vars is exist.

Hope the informations above are helpful.

Well sarge has become stable and such updates will not be allowed for
the package, unfortunatly.

Fix it in backports or take some notes for others, maybe. :-)


- -Andrew

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFC5zE4nQYz4bYlCYURAvIJAKDjHNitTMw7+aw3zGn2O8qbU4D97gCgsLAM
PmziFptDMz2DMULZPAMK0yo=
=t/+k
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#319856: newvserver script needs /etc/vservers/util-vserver-vars

[Andrew Lee]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

Hello Ola,

Ola Lundqvist wrote:

 Restarting rebootmgr.
 Stopping the reboot manager
 Starting the reboot manager
 
 
 Seems like you have upgraded from an earlier release. I do not think
 the reboot manager is here still.

Do you mean this reboot manager:
# ls /etc/init.d/rebootmgr -l
- -rwxr-xr-x  1 root root 1421 May 25 04:22 /etc/init.d/rebootmgr

It exist in all of my other machines too.

 Then you must have this file as a symlink...
 
 zircone:~# ls -l /usr/lib/util-vserver/util-vserver-vars
 -rw-r--r--  1 root root 4398 May 22 21:21 
 /usr/lib/util-vserver/util-vserver-vars
 It would be nice if you could check if the
 /usr/lib/util-vserver/util-vserver-vars is a file or symlink. If it
 points wrong we have the answer there. But if it don't we have some
 other issue. Possibly with just the sarge version and I must get
 an update into the stable relase.

It is a normal file:
# ls -l /usr/lib/util-vserver/util-vserver-vars
- -rw-r--r--  1 root root 4200 May 25 04:22
/usr/lib/util-vserver/util-vserver-vars

 I can add backports to my own archive. That is not a problem but
 users will not find it that easy. :)

True, does any better way that other package maintainers do?
I've looked at debian-policy, it mentioned:

_stable_
  This is the current released version of Debian GNU/Linux.
Once the distribution is _stable_ only security fixes and other major
bug fixes are allowed.  When changes are made to this distribution, the
release number is increased (for example: 2.2r1 becomes 2.2r2 then
2.2r3, etc).

Is this bug big enough for to put an fix into stable release?

Regards,

- -Andrew
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFC51ninQYz4bYlCYURAsM8AKDh+mlY/SxIc4awbLT5AV5u4DVAigCfWW1e
ufXg8XTNF1PzMqV+XrLm/8c=
=n92B
-END PGP SIGNATURE-


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#319856: newvserver script needs /etc/vservers/util-vserver-vars

[Andrew Lee]

Package: util-vserver
Version: 0.30.204-5sarge2
Severity: important

Hi Ola,

I found the old sarge has /etc/vservers/util-vserver-vars
And the new one(fresh installed sarge) does not.

It cause the newvserver script failed on build new vserver, because has 
no /etc/vservers/util-vserver-vars.

For solve this problem, just simply copy
/usr/lib/util-vserver/util-vserver-vars to /etc/vservers/

I will suggest to mention this in NEW or README.Debian or add it to
postinst.

Thank you for your wonderfull integration of vserver packages in Debian.

-- System Information:
Debian Release: 3.1
Architecture: i386 (i686)
Kernel: Linux 2.4.27-10vserver
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)

Versions of packages util-vserver depends on:
pn  iproute  Not found.
ii  libc6   2.3.2.ds1-22 GNU C Library: Shared libraries an
ii  libgcc1 1:3.4.3-13   GCC support library
ii  libstdc++5  1:3.3.5-13   The GNU Standard C++ Library v3
ii  net-tools   1.60-10  The NET-3 networking toolkit


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#301496: tasksel: Please refine chinese-t and chinese-t-desktop and add an important input method

[Andrew Lee]

Package: tasksel
Version: 2.24
Severity: important

Dear maintainer(s),

Since sarge is frozen, I know it's bacome difficult to make this change.
But this is an important input method - scim-chewing[1], people mostly
in Taiwan would like to see it into Sarge.

Fortunately, scim-chewing package got sponsored to uploaded into sid[2],
and hopefully into Sarge.

For providing better enviroment for our users, I wish you can accept
this changes for chinese-t:
- language-env
and these changes for chinese-t-desktop:
- cpanel
- chinput
+ scim-chewing
+ m17n-env

The language-env doesn't has Chinese supported yet, the cpanel is 
obsoleted and the chinput it mostly for Simplified Chinese users.

[1] 
http://lists.alioth.debian.org/pipermail/pkg-ime-devel/2005-March/000220.html
[2] http://lists.debian.org/debian-release/2005/03/msg00311.html

-- System Information:
Debian Release: 3.1
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: i386 (i686)
Kernel: Linux 2.6.10-ck5
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)

Versions of packages tasksel depends on:
ii  aptitude  0.2.15.8-1 terminal-based apt frontend
ii  debconf [debconf-2.0] 1.4.46 Debian configuration management sy
ii  liblocale-gettext-perl1.01-17Using libc functions for internati

-- debconf information excluded


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#301501: scim-chewing: Not installable

[Andrew Lee]

Package: scim-chewing
Version: 0.2.0-1
Severity: serious
Tags: sid
Justification: Policy 4.2

Not installable by depends on libatk1.0-0 (= 1.9.0) which is non exist
in sid.

-- System Information:
Debian Release: 3.1
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: i386 (i686)
Kernel: Linux 2.6.10-ck5
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)

Versions of packages scim-chewing depends on:
ii  libatk1.0-0 1.8.0-4  The ATK accessibility toolkit
ii  libc6   2.3.2.ds1-20 GNU C Library: Shared libraries an
ii  libchewing2 0.2.6-2  intelligent phonetic input method 
ii  libgcc1 1:3.4.3-12   GCC support library
ii  libglib2.0-02.6.3-1  The GLib library of C routines
ii  libgtk2.0-0 2.6.2-4  The GTK+ graphical user interface 
ii  libpango1.0-0   1.8.1-1  Layout and rendering of internatio
ii  libstdc++5  1:3.3.5-12   The GNU Standard C++ Library v3
ii  scim1.0.2-2  Smart Common Input Method platform

-- no debconf information


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#300692: scim: Incomplete dependency

[Andrew Lee]

Package: scim
Version: 1.0.2-2
Severity: serious
Tags: patch
Justification: Policy 5.6.9.


Dear maintainer(s),

I knew only one DD for help uploading package is not enought, and I
am very appreciate that he has done so much for scim package.

I hope more DD will stand up for helping on pkg-ime project. :-)

The scim-chewing is listed in Suggests, but doesn't exist in Debian 
pool yet.

The scim-chewing is an intelligent ZhuYin(bopomofo) input method for
SCIM which people mostly used in Taiwan.

So it is very an very important package for our Debian users.

It depends on libchewing package which the new version of im-sdk 
package depends on it too.

Now, the libchewing and scim-chewing are both available on:
svn://svn.debian.org/pkg-ime/

Please consider to make this as a RC bug, otherwise it will be 
impossible to see chewing included in Sarge.

Thank you in advance.

-- System Information:
Debian Release: 3.1
  APT prefers testing
  APT policy: (500, 'testing')
Architecture: i386 (i686)
Kernel: Linux 2.4.27-2-686-smp
Locale: LANG=C, LC_CTYPE=C (charmap=ANSI_X3.4-1968)

Versions of packages scim depends on:
ii  libatk1.0-0  1.8.0-4 The ATK accessibility toolkit
ii  libc62.3.2.ds1-20GNU C Library: Shared libraries an
ii  libgcc1  1:3.4.3-6   GCC support library
ii  libglib2.0-0 2.6.3-1 The GLib library of C routines
ii  libgtk2.0-0  2.6.2-3 The GTK+ graphical user interface 
ii  libpango1.0-01.8.1-1 Layout and rendering of internatio
ii  libstdc++5   1:3.3.5-8   The GNU Standard C++ Library v3
ii  libx11-6 4.3.0.dfsg.1-10 X Window System protocol client li
ii  xlibs4.3.0.dfsg.1-10 X Keyboard Extension (XKB) configu

-- no debconf information


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#298532: qemu: Fails to build from source

[Andrew Lee]

Package: qemu
Version: 0.6.1-1
Severity: important
Justification: fails to build from source

Dear maintainers,

Thanks for your work.

I tried to build this package from source by debuild on several
machines. But it failed on all the machines, I am not sure, maybe
something missed in control file? 

I have also installed these packages myself:
$ dpkg -l|grep libarts
ii  libarts1   1.3.2-2aRts Sound system
ii  libarts1-dev   1.3.2-2aRts Sound system (development files)
ii  libartsc0  1.3.2-2aRts Sound system C support library
ii  libartsc0-dev  1.3.2-2aRts Sound system C support library(develop

The debuild still failed with these error messages:

/usr/lib/libSDL.a(SDL_x11gl.o)(.text+0x917): In function
`X11_GL_LoadLibrary':
: warning: Using 'dlopen' in statically linked applications requires at
runtime the shared libraries from the glibc version used for linking
/usr/bin/ld: cannot find -lartsc
collect2: ld returned 1 exit status
make[2]: *** [qemu-fast] Error 1
make[2]: Leaving directory `/home/andrew/tmp/qemu-0.6.1/i386'
make[1]: *** [all] Error 1
make[1]: Leaving directory `/home/andrew/tmp/qemu-0.6.1'
make: *** [debian/stamp-makefile-build] Error 2
debuild: fatal error at line 764:
dpkg-buildpackage failed!


-- System Information:
Debian Release: 3.1
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: i386 (i686)
Kernel: Linux 2.6.10-ck5
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)

Versions of packages qemu depends on:
ii  bochsbios 2.1.1+20041109-3   BIOS for the Bochs emulator
ii  libc6 2.3.2.ds1-20   GNU C Library: Shared libraries an
ii  libsdl1.2debi 1.2.7+1.2.8cvs20041007-4.1 Simple DirectMedia Layer
ii  sharutils 1:4.2.1-11 shar, unshar, uuencode, uudecode
ii  vgabios   0.4c+20041014-1VGA BIOS software for the Bochs an
ii  zlib1g1:1.2.2-4  compression library - runtime

-- no debconf information


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#237723: Please fix the gateway between debian-chinese-* lists.

[Andrew Lee]

Hi guys,
I am so sorry to remind this again, but this outstanding bug has been
listed *319 days*.
Does anyone can give me some hits that how can we do for solving this
problem?
[ Taiwan Linux Users Group ]
Andrew Lee () http://wiki.debian.org.tw
Winkler Partners http://www.winklerpartners.com
My [EMAIL PROTECTED]: +886 2 2311 2345 cell: +886 968749 055
Wild at Heart Legal Defense Association http://ecosophy.org

Bug#291943: maint-guide: The example has description-synopsis-starts-with-a-capital-lettet

[Andrew Lee]

Package: maint-guide
Version: 1.2.2
Severity: minor

In the control file example:
 Description: A fully GUI configurable X file manager using GTK+

It should be:
Description: fully GUI configureable X file manager using GTK+

This has mentioned in developers-reference 6.2.2.

-- System Information:
Debian Release: 3.1
  APT prefers unstable
  APT policy: (500, 'unstable')
Architecture: i386 (i686)
Kernel: Linux 2.6.10-ck5
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8)

-- no debconf information


-- 
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]

Bug#218232: (forw) Re: APT translation to zh_TWy

[Andrew Lee]

How about these:
Get = 
Igr = 
Hit = 
-Andrew
Ambrose Li wrote:
Hi
sorry for not having responded earlier. I did not initially
respond because I live in Canada and is not very in touch
with actual correct terms, so I hesitated in responding with
a suggestion (and then forgot about it...).
However, reading from the web, I believe the following is
a reasonable translation:

(the context being something like
Hit http://non-us.debian.org unstable/non-US/main Packages)
My rationales are as follows:
1. This term is used in describing hits by proxies or caches
  (which is what the word hit means in the context)
2. It is (or more or less performs the function of) a verb
  describing a perfect action (which fits how it is used in apt)
3. It sounds ok compared to other possible translations I've
  seen
This suggested translation would result in typical APT output
like the following:
 http://non-us.debian.org unstable/non-US/main Packages
However, I do know that I'm mostly out of touch with the correct
technical terms, so I stand corrected.
Regards,
Ambrose Li
PS: Regarding the suggested translation of , my thoughts are:
1. It is not the usual word for describing hits of a proxy or
  cache, as far as I can see
2. It sounds like knock to me
On Wed, Jan 12, 2005 at 06:55:47AM +0100, Christian Perrier wrote:
 

Is there any objection to the following suggestion I received
privately?
If there is none, I guess that the change should be commited as a fix
to bug 218232.
PS: I hope I don't break encodings...this mail looks nice in my own
Emacs and the characters definitely look Chinesebut of course,
given my ignorance in your language, I can't read them.

- Forwarded message from yf.kuo [EMAIL PROTECTED] -
Date: Wed, 12 Jan 2005 07:48:17 +0800
From: yf.kuo [EMAIL PROTECTED]
To: Christian Perrier [EMAIL PROTECTED]
Subject: Re: APT translation to zh_TW
  is close to contact or touch. 
My opinnion is  Hit translation should be 


Christian Perrier :
   

Hello to all users and contributors from the zh8TW localisations in
Debian,
I hope I'm hitting the correct door for getting an answer.
If you look at http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=218232
you'll find that the bug reporter mentions he finds the current
translation of Hit in APT quite strange.
From his words:

 

apt-get translates the word Hit as  (touch, contact, etc.).
This is a very strange translation for the meaning of Hit used
by apt-get (that the item in its cache is up-to-date).
  

   

Matt Zimmerman, the package maintainer, requested him to suggest
another translation bug got no answer.
So, would you consider the following appropriate or not:
#: cmdline/acqprogress.cc:55
msgid Hit 
msgstr  
Moreover, I'm currently beginning to assist Matt in maintaining
translations for APT, just like I'm doing for several other package
maintainers as some of you may be aware.
Would it be possible that someone completes the attached partial
translation and send it as a bug report against the apt package?
But, don't wait for it for giving me your answer about the translation
of Hit.
Please take care of keeping all addresses CC'ed to your answers as I'm
not subscribed to the list and, anyway, it is important that answers
go into the Bug Tracking System.
Many thanks in advance.

 

- End forwarded message -
--