user-mode-linux-user Mailing List for User-mode Linux kernel port (Page 801)

> Hmm.. somehow this doesn't want to work. 

Make that "fake_arch".

You should see a message early during the boot saying that it's switching its 
idea of its arch.

> Since I started booting umls with the 'debug' option, the panics
> didn't come back (yet). Excellent panic-repellant, it seems. 

Yeah, races tend to go away.  Are you running test7 yet?  Have you seen that 
panic in test7?

> --- linuxdev/arch/um/kernel/process_kern.c	Sat Aug 26 13:57:12 2000
> +++ linuxdevbr/arch/um/kernel/process_kern.c	Sun Aug 27 16:01:28 2000
> @@ -694,6 +694,8 @@
>  	return(current->thread.fault_addr);
>  }
>  +EXPORT_SYMBOL(get_fault_addr);
>  +
>  void set_fault_addr(void *addr)
>  {
>  	current->thread.fault_addr = addr; 

Thanks, that's applied...

				Jeff

vm
--
bash# insmod ip_tables
bash# insmod iptable_filter.o
bash# iptables -L -v                  <== seems to work
bash# insmod iptable_mangle.o 
<hang>


host debugger
-------------
Breakpoint 1, start_kernel () at init/main.c:514
514             printk(linux_banner);
(gdb) break signal_segv
Breakpoint 2 at 0x100e1323: file trap_user.c, line 27.
(gdb) break panic
Breakpoint 3 at 0x10007164: file panic.c, line 54.
(gdb) cont
Continuing.

Breakpoint 2, signal_segv (sig=11) at trap_user.c:27
27              write(2, "Seg fault in signals\n", strlen("Seg fault in signals\n"));
(gdb) bt
#0  signal_segv (sig=11) at trap_user.c:27
#1  0x100e7478 in __restore ()
    at ../sysdeps/unix/sysv/linux/i386/sigaction.c:127
#2  0x1008653c in nf_hook_slow (pf=2, hook=0, skb=0x50fe8680, 
    indev=0x10206878, outdev=0x0, okfn=0x100a4354 <ip_rcv_finish>)
    at netfilter.c:464
#3  0x100a41f8 in ip_rcv (skb=0x50fe8680, dev=0x10206878, pt=0x10201a40)
    at ip_input.c:424
#4  0x1008aabb in net_rx_action (h=0x1020d870) at dev.c:1307
#5  0x1000b725 in do_softirq () at softirq.c:77
#6  0x100dd071 in do_IRQ (irq=0, user_mode=0) at irq.c:330
#7  0x100e05b4 in timer_handler (sig=14) at time_kern.c:37
#8  0x100e7478 in __restore ()
    at ../sysdeps/unix/sysv/linux/i386/sigaction.c:127
#9  0x100e2b71 in _switch_to (prev=0x10174000, next=0x507bc000)
    at process_kern.c:214
#10 0x10004e4c in schedule () at sched.c:636
#11 0x100e3003 in do_idle () at process_kern.c:422
#12 0x100e30a2 in cpu_idle () at process_kern.c:451
#13 0x101288df in start_kernel () at init/main.c:591
#14 0x100e1942 in start_kernel_proc (unused=0x0) at um_arch.c:72
#15 0x100e139f in signal_tramp (arg=0x100e1908) at trap_user.c:49
(gdb) 

On Sat, 19 Aug 2000, Jeff Dike wrote:

> > Funny thing is that it thinks it's running on an um processor. Or
> > something. Another thing that goofs up is that my bash login scripts
> > add ~/bin.`uname -m` to my path, which works perfectly fine on
> > {i386,sparc,sun4u} machines, but not on any of the virtual machines
> > here (quite a few already...)
> 
> If you don't like 'um' as your arch, put 'fakearch' on the kernel command 
> line.
> 
> That will make it assume the underlying arch.

Hmm.. somehow this doesn't want to work.


> > Now this is of course easy to kludge around, but wouldn't it be saner
> > if the uml 'kernel' just returned the name of the host architecture to
> > 'uname -m' instead of just 'um'? There's not really supposed to be
> > anything that distinguishes this virtual machine from a real i386,
> > right? 
> 
> I'm open to arguments on this one.  It sort of seems like the right
> thing to do.
> 
> It also happens automatically, which contributes to its rightness.  In the 
> kernel pool, $ARCH is set to 'um' which causes it to build in arch/um.  $ARCH 
> is automatically used to fill in the utsname structure.  I'd have to modify 
> the generic kernel in order to change that.

bash# hostname
uml0
bash# rpm -i bridge-utils-0.9.0-1.i386.rpm         
package bridge-utils-0.9.0-1 is for a different architecture
bash# rpm -i bridge-utils-0.9.0-1.i386.rpm --force
package bridge-utils-0.9.0-1 is for a different architecture
bash#


> > (Apart from some NFS unmount hangs (which might be in stock
> > 2.4.0-test6 too, didn't check) and an occasional kernel panic once a
> > day, these virtual machines seem to be working remarkably well.) 
> 
> How is a kernel panic once a day working remarkably well?

I didn't say that. :-)


> And why don't you tell me when it panics?

I just did.


> I can't fix things unless I know about them.

Obviously.


> And until now, I didn't know about any extant panics.
> 
> So, what is the panic, and what's the backtrace, and do you know how
> to reproduce it?

Since I started booting umls with the 'debug' option, the panics didn't
come back (yet). Excellent panic-repellant, it seems.


> > When trying to load the ip_tables module in an uml I get:
> > [root@dev0 netfilter]# insmod ./ip_tables.o 
> > ./ip_tables.o: unresolved symbol get_fault_addr 
> > ./ip_tables.o: unresolved symbol set_fault_addr
> > ./ip_tables.o: unresolved symbol current_task 
> 
> They just haven't been exported yet.  Stick EXPORT_SYMBOL in the appropriate 
> places, and it should work.  Then send me the patch.

Yes, sir!

greetings,
Lennert


--- linuxdev/arch/um/kernel/process_kern.c	Sat Aug 26 13:57:12 2000
+++ linuxdevbr/arch/um/kernel/process_kern.c	Sun Aug 27 16:01:28 2000
@@ -694,6 +694,8 @@
 	return(current->thread.fault_addr);
 }
 
+EXPORT_SYMBOL(get_fault_addr);
+
 void set_fault_addr(void *addr)
 {
 	current->thread.fault_addr = addr;

an...@su... said:
> To link the final `linux` executable I need this patch: 

Thanks.  

I think gcc must have changed its behavior at some point because obviously I 
don't see that problem.

				Jeff

> if I start uml in a gnome-terminal, log in there and issue a command
> that generates a lot of output, about everything after line 50 is
> lost. At that point I am 'back at the prompt': Sometimes I dont't see
> the prompt, but I can type new commands.

The console has been like that forever.  It's one of those fairly harmless 
things that I haven't bothered chasing down yet.

> It does not manifest if I telnet into the virtual machine. 2.4.0-test6
> exhibited the same (buggy) behaviour.

Which is why I think the problem is in the console driver.

				Jeff

On Fri, 25 Aug 2000, Jeff Dike wrote:

>The user-mode port of 2.4.0-test7 is available.

To link the final `linux` executable I need this patch:

--- ./arch/um/Makefile.~1~	Sat Aug 26 17:36:29 2000
+++ ./arch/um/Makefile	Sat Aug 26 17:48:28 2000
@@ -47,7 +47,7 @@
 linux: $(ARCH_SYMLINKS) $(ARCH_DIR)/main.o vmlinux $(ARCH_DIR)/link.ld
 	mv vmlinux vmlinux.o
 	gcc -Wl,-T,$(ARCH_DIR)/link.ld $(LINK_PROFILE) -o linux -static \
-		$(ARCH_DIR)/main.o vmlinux.o
+		$(ARCH_DIR)/main.o vmlinux.o -L/usr/lib
 	rm -f $(ARCH_DIR)/link.ld
 
 USER_CFLAGS = $(patsubst -I%,,$(CFLAGS))

Andrea

Hi,

if I start uml in a gnome-terminal, log in there and issue a command that
generates a lot of output, about everything after line 50 is lost. At that
point I am 'back at the prompt': Sometimes I dont't see the prompt, but I
can type new commands.

Here is sample output:

[buytenh@vtfs buytenh]$ cd /usr
[buytenh@vtfs /usr]$ cd bin
[buytenh@vtfs bin]$ ls
Mail           epstopdf        latex           pfbtops          sun2mime
[lines snipped]
charset        gftopk          metasend        refer            unicode_stop
chattr         gftype          mf              remsync          uniq
checkalias     gindxbib        mft             rename           units
chfn           glibcbug        mimencode       renice           buytenh@vtfs bin]$ 

Note the odd place of the prompt. It does not manifest if I telnet into
the virtual machine. 2.4.0-test6 exhibited the same (buggy) behaviour.

Sounds like some kind of flow control problem?


greetings,
Lennert

The user-mode port of 2.4.0-test7 is available.

It's been updated to 2.4.0-test7.
A build bug which caused symbols not to be exported from arch/um/kernel has 
been fixed.
The debugging options are now configurable.

My ALS paper on this port has been posted on the project web site at
http://user-mode-linux.sourceforge.net/als2000/index.html (HTML) and
http://user-mode-linux.sourceforge.net/als2000.tex (TeX).

All the downloads except the Red Hat package have been updated.  I'm doing 
some work on the mkrootfs script, and it will be updated when that's done.

The project's home page is http://user-mode-linux.sourceforge.net

The project's download page is http://sourceforge.net/project/filelist.php?grou
p_id=429

				Jeff

On Fri, Aug 25, 2000 at 01:50:56PM +0100, David Woodhouse wrote:
> I don't comprehend. The flag is being set only in the struct sock 
> which is used by the netlink_dev. It's not being set anywhere else. Only 
> operations on that particular socket will bypass the capability check.
> 
> Other users can create their own socket, which won't have the same flag
> set. How can they access the socket which is being used by the netlink_dev,
> without actually going through the permissions check required to open 
> /dev/tap$n ?

Yes, I misread the code. There is no hole.


-Andi

da...@re... said:
>  Looks fine, you'll want to resend this to Alan in a few weeks when he
> starts up 2.2.18 :-) 


ak...@su... said:
>  A nlsocket with opened character devices can still be accessed via
> sockets too, so you just opened a security hole. 

I don't comprehend. The flag is being set only in the struct sock 
which is used by the netlink_dev. It's not being set anywhere else. Only 
operations on that particular socket will bypass the capability check.

Other users can create their own socket, which won't have the same flag
set. How can they access the socket which is being used by the netlink_dev,
without actually going through the permissions check required to open 
/dev/tap$n ?


--
dwmw2

On Fri, Aug 25, 2000 at 01:28:42PM +0100, David Woodhouse wrote:
> 
> ku...@ms... said:
> >  Ethertap device has just been replaced. 
> >  netlink_dev is open for removal rather than for improvements. 
> 
> OK. The new Ethertap in 2.4 looks far nicer. 
> 
> 2.2 is still a problem though. I'd like to see either the new Ethertap or
> this patch go in.
> 
> Index: include/net/sock.h
> ===================================================================
> RCS file: /inst/cvs/linux/include/net/sock.h,v
> retrieving revision 1.8
> diff -u -r1.8 sock.h
> --- include/net/sock.h	2000/06/07 09:55:39	1.8
> +++ include/net/sock.h	2000/08/23 12:05:09
> @@ -115,6 +115,7 @@
>  	unsigned		groups;
>  	pid_t			dst_pid;
>  	unsigned		dst_groups;
> +	int			netlink_dev;
>  	int			(*handler)(int unit, struct sk_buff *skb);
>  	atomic_t		locks;
>  	struct netlink_callback	*cb;
> Index: net/netlink/af_netlink.c
> ===================================================================
> RCS file: /inst/cvs/linux/net/netlink/af_netlink.c,v
> retrieving revision 1.5
> diff -u -r1.5 af_netlink.c
> --- net/netlink/af_netlink.c	2000/06/07 09:54:25	1.5
> +++ net/netlink/af_netlink.c	2000/08/23 12:05:50
> @@ -254,7 +254,8 @@
>  		return -EINVAL;
>  
>  	/* Only superuser is allowed to listen multicasts */
> -	if (nladdr->nl_groups && !capable(CAP_NET_ADMIN))
> +	if (nladdr->nl_groups && !sk->protinfo.af_netlink.netlink_dev &&
> +	    !capable(CAP_NET_ADMIN))
>  		return -EPERM;

A nlsocket with opened character devices can still be accessed via sockets too,
so you just opened a security hole.


-Andi

ku...@ms... said:
>  Ethertap device has just been replaced. 
>  netlink_dev is open for removal rather than for improvements. 

OK. The new Ethertap in 2.4 looks far nicer. 

2.2 is still a problem though. I'd like to see either the new Ethertap or
this patch go in.

Index: include/net/sock.h
===================================================================
RCS file: /inst/cvs/linux/include/net/sock.h,v
retrieving revision 1.8
diff -u -r1.8 sock.h
--- include/net/sock.h	2000/06/07 09:55:39	1.8
+++ include/net/sock.h	2000/08/23 12:05:09
@@ -115,6 +115,7 @@
 	unsigned		groups;
 	pid_t			dst_pid;
 	unsigned		dst_groups;
+	int			netlink_dev;
 	int			(*handler)(int unit, struct sk_buff *skb);
 	atomic_t		locks;
 	struct netlink_callback	*cb;
Index: net/netlink/af_netlink.c
===================================================================
RCS file: /inst/cvs/linux/net/netlink/af_netlink.c,v
retrieving revision 1.5
diff -u -r1.5 af_netlink.c
--- net/netlink/af_netlink.c	2000/06/07 09:54:25	1.5
+++ net/netlink/af_netlink.c	2000/08/23 12:05:50
@@ -254,7 +254,8 @@
 		return -EINVAL;
 
 	/* Only superuser is allowed to listen multicasts */
-	if (nladdr->nl_groups && !capable(CAP_NET_ADMIN))
+	if (nladdr->nl_groups && !sk->protinfo.af_netlink.netlink_dev &&
+	    !capable(CAP_NET_ADMIN))
 		return -EPERM;
 
 	if (sk->protinfo.af_netlink.pid) {
@@ -506,7 +507,8 @@
 			return -EINVAL;
 		dst_pid = addr->nl_pid;
 		dst_groups = addr->nl_groups;
-		if (dst_groups && !capable(CAP_NET_ADMIN))
+		if (dst_groups && !sk->protinfo.af_netlink.netlink_dev &&
+		    !capable(CAP_NET_ADMIN))
 			return -EPERM;
 	} else {
 		dst_pid = sk->protinfo.af_netlink.dst_pid;
Index: net/netlink/netlink_dev.c
===================================================================
RCS file: /inst/cvs/linux/net/netlink/netlink_dev.c,v
retrieving revision 1.2
diff -u -r1.2 netlink_dev.c
--- net/netlink/netlink_dev.c	2000/06/07 09:54:25	1.2
+++ net/netlink/netlink_dev.c	2000/08/23 12:05:56
@@ -25,6 +25,7 @@
 #include <linux/netlink.h>
 #include <linux/poll.h>
 #include <linux/init.h>
+#include <net/sock.h>
 
 #include <asm/system.h>
 #include <asm/uaccess.h>
@@ -134,6 +135,7 @@
 	memset(&nladdr, 0, sizeof(nladdr));
 	nladdr.nl_family = AF_NETLINK;
 	nladdr.nl_groups = ~0;
+	sock->sk->protinfo.af_netlink.netlink_dev = 1;
 	if ((err = sock->ops->bind(sock, (struct sockaddr*)&nladdr, sizeof(nladdr))) < 0) {
 		sock_release(sock);
 		goto out;


--
dwmw2

> I take it you roll fixes in per-Torvalds release then? 

I put fixes in CVS as I get them.  I make official releases one per Linus 
release mostly.  Ocassionally, I skip one of his or make two releases for one 
of his.

				Jeff

On Tue, 22 Aug 2000, Jeff Dike wrote:

> > I got uml to hang now. No panic, but instead a cryptic
> > [buytenh@vtfs /]$ w 
> > Seg fault in signals 
> 
> Are you running the stock test6?
> 
> If so, you should grab the latest cvs.  I put a fix in for something a lot 
> like this.  If you don't want to grab cvs, then look at the two most recent 
> patches I posted to the devel list and apply them.
> 
> If you can get it to crash then, I'll take it somewhat more seriously :-)

I take it you roll fixes in per-Torvalds release then?


greetings,
Lennert

(BTW, this is a much better place for this kind of question than the forums on 
Sourceforge.  I don't think anyone but me actually pays any kind of attention 
to them :-)

> Why doesnt UML find the symbols?? (btw. cat /proc/ksyms does not show
> set_signals). 

It doesn't find the symbols because I build arch/um/kernel wrong.  This will 
be fixed in test7.

				Jeff

hi

I have a very strange problem with UML. I am trying to load a kernel module 
(chardev driver) which I compiled under UML using the UML patched linux 
2.4.0-test6 source. I load my kernel module and UML keeps telling me: 
unresolved symbol: set_signals.
Now I searched arch/um/kernel and in ksyms.c there is 
EXPORT_SYMBOL(set_signals).
The source can be found in signal_user.c.

Why doesnt UML find the symbols?? (btw. cat /proc/ksyms does not show 
set_signals).

Can anybody help me, please?

Regards

- Rainer Burgstaller
				

Hello!

> >  The ethertap driver requires CAP_NET_ADMIN and ignores the bits on /
> > dev/tap*.   I think Alexey would accept a patch that changes this. 

Ethertap device has just been replaced.


> This patch does it. It looks like it's feasible to do it as non-root with 
> PF_NETLINK sockets, but then it's available to _any_ user, which isn't much 
> better. We need to be able to restrict it to a single user/group.

Netlink is broadcast media. Access control is made per message
and depends on message kind. Any client knows who sent the packet.

netlink_dev is open for removal rather than for improvements.

User/group access to netlink is advertised (though it is _not_ more
fine grain, but rther too coarce from netlink viewpoint, see above),
but certainly not using character device interface.
Using vfs facilities, probably.

Alexey

> I got uml to hang now. No panic, but instead a cryptic
> [buytenh@vtfs /]$ w 
> Seg fault in signals 

Are you running the stock test6?

If so, you should grab the latest cvs.  I put a fix in for something a lot 
like this.  If you don't want to grab cvs, then look at the two most recent 
patches I posted to the devel list and apply them.

If you can get it to crash then, I'll take it somewhat more seriously :-)

				Jeff

Hi,


I got uml to hang now. No panic, but instead a cryptic

[buytenh@vtfs /]$ w
Seg fault in signals

After this it hangs. It gave me this after doing 'ls -R /' twice. Among
the mounted volumes is one NFSv3 mount.


If I stop it, I get this backtrace:

(gdb) bt
#0  0x100ad0f1 in __gettimeofday ()
#1  0x1009fb2b in timer (irq=0, dev=0x0, regs=0x1011f6c4) at
time_kern.c:57
#2  0x1009caef in handle_IRQ_event (irq=0, regs=0x1011f6c4,
action=0x5005b320)
    at irq.c:148
#3  0x1009cc8f in do_IRQ (irq=0, user_mode=0) at irq.c:313
#4  0x1009fad4 in timer_handler (sig=14) at time_kern.c:37
#5  0x100a7a18 in __restore ()
    at ../sysdeps/unix/sysv/linux/i386/sigaction.c:127
#6  0x100a19c1 in stop () at user_util.c:194
#7  0x100a07d6 in signal_segv (sig=11) at trap_user.c:29
#8  0x100a7a18 in __restore ()
    at ../sysdeps/unix/sysv/linux/i386/sigaction.c:127
#9  0x1007efb8 in tcp_ack (sk=0x50a7d0e0, th=0x5013b824,
ack_seq=2089077595, 
    ack=3280287705, len=276) at tcp_input.c:1105
#10 0x10080e2b in tcp_rcv_established (sk=0x50a7d0e0, skb=0x501021c0, 
    th=0x5013b824, len=276) at tcp_input.c:2662
#11 0x1008747d in tcp_v4_do_rcv (sk=0x50a7d0e0, skb=0x501021c0)
    at tcp_ipv4.c:1573
#12 0x100877b9 in tcp_v4_rcv (skb=0x501021c0, len=276) at tcp_ipv4.c:1667
#13 0x100762f0 in ip_local_deliver (skb=0x501021c0) at ip_input.c:260
#14 0x1007660c in ip_rcv (skb=0x501021c0, dev=0x1012d658, pt=0x10129a40)
    at ip_input.c:370
#15 0x1006f26b in net_rx_action (h=0x10134870) at dev.c:1306
#16 0x10009655 in do_softirq () at softirq.c:77
#17 0x1009ccc1 in do_IRQ (irq=1, user_mode=0) at irq.c:330
#18 0x1009d3bd in sigio_handler (sig=29) at irq_user.c:53
#19 0x100a7a18 in __restore ()
    at ../sysdeps/unix/sysv/linux/i386/sigaction.c:127
#20 0x1009e26f in do_idle () at process_kern.c:424
#21 0x1009e302 in cpu_idle () at process_kern.c:450
#22 0x100e8e75 in start_kernel () at init/main.c:592
#23 0x100a10a2 in start_kernel_proc (unused=0x0) at um_arch.c:72
#24 0x100a083f in signal_tramp (arg=0x100a1068) at trap_user.c:50


If I resume it again, I again get 'Seg fault in signals' on the console. I
try to ping it, but nothing comes back. If I then stop it again I get:

#0  0x100ad2f1 in __libc_nanosleep ()
#1  0x100ad2ad in __sleep (seconds=1000000)
    at ../sysdeps/unix/sysv/linux/sleep.c:82
#2  0x100a19c1 in stop () at user_util.c:194
#3  0x100a07d6 in signal_segv (sig=11) at trap_user.c:29
#4  0x100a7a18 in __restore ()
    at ../sysdeps/unix/sysv/linux/i386/sigaction.c:127
#5  0x100a5bfb in umn_rcv (data=0x1012ca9c "E", len=296) at umn_kern.c:50
#6  0x100a5c45 in slip_unesc (s=192) at umn_kern.c:65
#7  0x100a5805 in umn_read (fd=17) at umn_user.c:96
#8  0x100a5cd2 in umn_handler (irq=1, dev=0x1012ca80, unused=0x1011f4e0)
    at umn_kern.c:98
#9  0x1009caef in handle_IRQ_event (irq=1, regs=0x1011f4e0,
action=0x50c03260)
    at irq.c:148
#10 0x1009cc8f in do_IRQ (irq=1, user_mode=0) at irq.c:313
#11 0x1009d3bd in sigio_handler (sig=29) at irq_user.c:53
#12 0x100a7a18 in __restore ()
    at ../sysdeps/unix/sysv/linux/i386/sigaction.c:127
#13 0x1009caef in handle_IRQ_event (irq=0, regs=0x1011f6c4,
action=0x5005b320)
    at irq.c:148
#14 0x1009cc8f in do_IRQ (irq=0, user_mode=0) at irq.c:313
#15 0x1009fad4 in timer_handler (sig=14) at time_kern.c:37
#16 0x100a7a18 in __restore ()
#17 0x100a19c1 in stop () at user_util.c:194
#18 0x100a07d6 in signal_segv (sig=11) at trap_user.c:29
#19 0x100a7a18 in __restore ()
    at ../sysdeps/unix/sysv/linux/i386/sigaction.c:127
#20 0x1007efb8 in tcp_ack (sk=0x50a7d0e0, th=0x5013b824,
ack_seq=2089077595, 
    ack=3280287705, len=276) at tcp_input.c:1105
#21 0x10080e2b in tcp_rcv_established (sk=0x50a7d0e0, skb=0x501021c0, 
    th=0x5013b824, len=276) at tcp_input.c:2662
#22 0x1008747d in tcp_v4_do_rcv (sk=0x50a7d0e0, skb=0x501021c0)
    at tcp_ipv4.c:1573
#23 0x100877b9 in tcp_v4_rcv (skb=0x501021c0, len=276) at tcp_ipv4.c:1667
#24 0x100762f0 in ip_local_deliver (skb=0x501021c0) at ip_input.c:260
#25 0x1007660c in ip_rcv (skb=0x501021c0, dev=0x1012d658, pt=0x10129a40)
    at ip_input.c:370
#26 0x1006f26b in net_rx_action (h=0x10134870) at dev.c:1306
#27 0x10009655 in do_softirq () at softirq.c:77
#28 0x1009ccc1 in do_IRQ (irq=1, user_mode=0) at irq.c:330
#29 0x1009d3bd in sigio_handler (sig=29) at irq_user.c:53
#30 0x100a7a18 in __restore ()
    at ../sysdeps/unix/sysv/linux/i386/sigaction.c:127
#31 0x1009e26f in do_idle () at process_kern.c:424
#32 0x1009e302 in cpu_idle () at process_kern.c:450
#33 0x100e8e75 in start_kernel () at init/main.c:592
#34 0x100a10a2 in start_kernel_proc (unused=0x0) at um_arch.c:72
#35 0x100a083f in signal_tramp (arg=0x100a1068) at trap_user.c:50


No idea whether this helps in any way. I can leave it in this state in
case there are other things you want to know, but I won't be back here
until Saturday at least.



greetings,
Lennert

jd...@ka... said:
>  The ethertap driver requires CAP_NET_ADMIN and ignores the bits on /
> dev/tap*.   I think Alexey would accept a patch that changes this. 

This patch does it. It looks like it's feasible to do it as non-root with 
PF_NETLINK sockets, but then it's available to _any_ user, which isn't much 
better. We need to be able to restrict it to a single user/group.

Index: include/linux/netlink.h
===================================================================
RCS file: /inst/cvs/linux/include/linux/netlink.h,v
retrieving revision 1.1.1.1
diff -u -r1.1.1.1 netlink.h
--- include/linux/netlink.h	2000/06/07 08:41:09	1.1.1.1
+++ include/linux/netlink.h	2000/08/22 19:08:11
@@ -141,6 +141,21 @@
 	return nlh;
 }
 
+struct netlink_opt
+{
+	u32			pid;
+	unsigned		groups;
+	u32			dst_pid;
+	unsigned		dst_groups;
+	unsigned long		state;
+	int			netlink_dev;
+	int			(*handler)(int unit, struct sk_buff *skb);
+	wait_queue_head_t	wait;
+	struct netlink_callback	*cb;
+	spinlock_t		cb_lock;
+	void			(*data_ready)(struct sock *sk, int bytes);
+};
+
 #define NLMSG_PUT(skb, pid, seq, type, len) \
 ({ if (skb_tailroom(skb) < (int)NLMSG_SPACE(len)) goto nlmsg_failure; \
    __nlmsg_put(skb, pid, seq, type, len); })
Index: net/netlink/af_netlink.c
===================================================================
RCS file: /inst/cvs/linux/net/netlink/af_netlink.c,v
retrieving revision 1.4.2.10
diff -u -r1.4.2.10 af_netlink.c
--- net/netlink/af_netlink.c	2000/07/06 15:28:51	1.4.2.10
+++ net/netlink/af_netlink.c	2000/08/22 19:31:08
@@ -46,20 +46,6 @@
 
 #define BUG_TRAP(x) if (!(x)) { printk("Assertion (" #x ") failed at " __FILE__ "(%d):" __FUNCTION__ "\n", __LINE__); }
 
-struct netlink_opt
-{
-	u32			pid;
-	unsigned		groups;
-	u32			dst_pid;
-	unsigned		dst_groups;
-	unsigned long		state;
-	int			(*handler)(int unit, struct sk_buff *skb);
-	wait_queue_head_t	wait;
-	struct netlink_callback	*cb;
-	spinlock_t		cb_lock;
-	void			(*data_ready)(struct sock *sk, int bytes);
-};
-
 static struct sock *nl_table[MAX_LINKS];
 static DECLARE_WAIT_QUEUE_HEAD(nl_table_wait);
 
@@ -309,7 +295,8 @@
 		return -EINVAL;
 
 	/* Only superuser is allowed to listen multicasts */
-	if (nladdr->nl_groups && !capable(CAP_NET_ADMIN))
+	if (nladdr->nl_groups && !sk->protinfo.af_netlink->netlink_dev &&
+	    !capable(CAP_NET_ADMIN))
 		return -EPERM;
 
 	if (sk->protinfo.af_netlink->pid) {
@@ -563,7 +550,8 @@
 			return -EINVAL;
 		dst_pid = addr->nl_pid;
 		dst_groups = addr->nl_groups;
-		if (dst_groups && !capable(CAP_NET_ADMIN))
+		if (dst_groups && !sk->protinfo.af_netlink->netlink_dev &&
+		    !capable(CAP_NET_ADMIN))
 			return -EPERM;
 	} else {
 		dst_pid = sk->protinfo.af_netlink->dst_pid;
Index: net/netlink/netlink_dev.c
===================================================================
RCS file: /inst/cvs/linux/net/netlink/netlink_dev.c,v
retrieving revision 1.1.1.1.2.8
diff -u -r1.1.1.1.2.8 netlink_dev.c
--- net/netlink/netlink_dev.c	2000/07/13 10:13:52	1.1.1.1.2.8
+++ net/netlink/netlink_dev.c	2000/08/22 19:16:24
@@ -27,6 +27,8 @@
 #include <linux/init.h>
 #include <linux/devfs_fs_kernel.h>
 #include <linux/smp_lock.h>
+#include <net/sock.h>
+#include <linux/netlink.h>
 
 #include <asm/system.h>
 #include <asm/uaccess.h>
@@ -123,6 +125,7 @@
 	memset(&nladdr, 0, sizeof(nladdr));
 	nladdr.nl_family = AF_NETLINK;
 	nladdr.nl_groups = ~0;
+	sock->sk->protinfo.af_netlink->netlink_dev = 1;
 	if ((err = sock->ops->bind(sock, (struct sockaddr*)&nladdr, sizeof(nladdr))) < 0) {
 		sock_release(sock);
 		goto out;





--
dwmw2

ak...@su... said:
>  Using /dev/tap* is obsolete anyways, use PF_NETLINK sockets instead. 

Please demonstrate how to do so without root privileges - which _is_ possible 
with a fairly minor fix to the netlink chardevice. 

Unless PF_NETLINK provides all functionality that the chardevice can 
provide, it can hardly be said to obsolete it.

--
dwmw2

On Tue, Aug 22, 2000 at 03:21:17PM -0500, Jeff Dike wrote:
> bu...@gn... said:
> > Apparently it checks for some POSIX capability on open. It shouldn't
> > be too hard to dike it out though, but that _will_ require
> > modifications to each and every kernel you want to run it on.
> 
> The ethertap driver requires CAP_NET_ADMIN and ignores the bits on /dev/tap*.  
> I think Alexey would accept a patch that changes this.

Using /dev/tap* is obsolete anyways, use PF_NETLINK sockets instead.


-Andi

bu...@gn... said:
> Apparently it checks for some POSIX capability on open. It shouldn't
> be too hard to dike it out though, but that _will_ require
> modifications to each and every kernel you want to run it on.

The ethertap driver requires CAP_NET_ADMIN and ignores the bits on /dev/tap*.  
I think Alexey would accept a patch that changes this.

> I've been looking at the present preferred way of communication (eth?
> devices), but I'm not too happy about those.. the level of isolation
> between virtual machines seems sub-optimal.

Care to elaborate on that?

> For now I'm busy chasing a panic that won't reproduce when run under
> the debugger... :-) 

Yummy.  My favorite kind of bug...

				Jeff

bu...@gn... said:

> [buytenh@mara buytenh]$ ls -al /dev/tap0
> crw-rw-rw-    1 buytenh  admins    36,  16 Aug 16 18:32 /dev/tap0
> [buytenh@mara buytenh]$ cat /dev/tap0
> cat: /dev/tap0: Operation not permitted

Aha. I consider that a bug in the netlink implementation.

We should make netlink_bind() bypass the capability check iff it's being 
invoked on behalf of the netlink chardevice.



--
dwmw2

On Tue, 22 Aug 2000, David Woodhouse wrote:

> >  I think you have never tested something like this. 
> 
> You're right. I was about to hack it up. Would you care to enlighten me 
> about what I'll discover, and save me the trouble? :)

Hehehe.. if you be so kind, I cannot refuse! :-)

[buytenh@mara buytenh]$ ls -al /dev/tap0
crw-rw-rw-    1 buytenh  admins    36,  16 Aug 16 18:32 /dev/tap0
[buytenh@mara buytenh]$ cat /dev/tap0
cat: /dev/tap0: Operation not permitted
[buytenh@mara buytenh]$ su
Password: 
[root@mara buytenh]# cat /dev/tap0
FET@
       s9^*
 !"#$%&'()*+,-./012345678PET@
                                s9 
 !"#$%&'()*+,-./01234567ET@
                                s9/
 !"#$%&'()*+,-./01234567ET@
                              s9?
 !"#$%&'()*+,-./01234567


While writing a TCP implementation in userland and wanting to use this
construction I encountered the same problem. Apparently it checks for some
POSIX capability on open. It shouldn't be too hard to dike it out though,
but that _will_ require modifications to each and every kernel you want to
run it on.

I've been looking at the present preferred way of communication (eth?
devices), but I'm not too happy about those.. the level of isolation
between virtual machines seems sub-optimal. I'm sure more thought will go
into this on my part.

For now I'm busy chasing a panic that won't reproduce when run under the
debugger... :-)



greetings,
Lennert