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

Jeff Dike <jd...@ka...> writes:
> I was a bit slow to catch on, though.  I think Lars noticed sooner.  When I 
> got up, I had a piece of mail from him asking me to change his link on my 
> thanks page from the "mailto:" thing to a pointer to his home page.  I think 
> he was trying to get some traffic from my slashdotting.

Not exactly.  The Slashdot article triggered me to go look at the UML
pages to see what had changed since the last time I looked at them.
(The look good, by the way!)  I happened to see a mailto URL referring
to my email adress.  In an attemt to avoid some spam, I asked Jeff to
change it to my home page URL instead.

wst...@po... said:
> 	Have you seen the UML article on slashdot.org? 

It was hard to miss from my web logs...

That was a complete surprise.  I had given up on slashdot.  And if they ever 
did run anything about UML, I would have expected something like:

From the will-you-please-leave-us-alone-now-Bill dept.

wstearns has been spamming us continuously for the last three months with the 
news that : "..."

I was a bit slow to catch on, though.  I think Lars noticed sooner.  When I 
got up, I had a piece of mail from him asking me to change his link on my 
thanks page from the "mailto:" thing to a pointer to his home page.  I think 
he was trying to get some traffic from my slashdotting.

That was good for some 40000 hits on the site, plus about 450 downloads sos 
far.  Maybe it will also pursuade some people going to ALS that they should 
attend my talk...

				Jeff

> I think it would still be nice to avoid root altogether where
> possible.  Seems to me that something like slirp
> (http://slirp.sourceforge.net/) could be useful
> here.

I asked about this in the forums, where no one lurk :-)

It would be cool if the virtual serial line
of UML would support SLIP discipline

then, we launch slirp the user-space SLIP emulator in the host
attached to the host side of the virtual serial line,
 and slattach the other side in UML

Then perhaps we could run nfsd as user on the host,
and mount it from uml.

--QAA23634.971101332/tanit.enserb.u-bordeaux.fr--

On Saturday, 7 Oct 2000, Jeff Dike wrote:

> epa...@up... said:
> > Many sysadmins (myself included) get very nervous when users ask
> > for a suid helper.
> 
> There's another possibility.  The eth daemon can be made to
> communicate with its peers on other boxes (which is a good idea in
> its own right), and you could set up a virtual network that has
> non-privileged daemons, except for one running as root on a machine
> that no one cares about.  That one would be the gateway to the
> outside world for all the others.

I think it would still be nice to avoid root altogether where
possible.  Seems to me that something like slirp
(http://slirp.sourceforge.net/) could be useful here.

Chris
-- 
Chris Emerson, obsessed Cambridge juggler
E-mail: cem...@ch...
Web page: http://www.chiark.greenend.org.uk/~cemerson/

Hi all,
  I was wondering about what would be the method to configure a SLIP
server for linux. I have SLIP compiled into my kernel (without CSLIP) but
I do not know the device name for a slip device, or what its major/minor
numbers are. I also can't seem to find a howto for a slip server using
google- I find only docs for slip clients.
  If you know of a document describing the process, please send it to me
or send a URL, I'd love to RTFM if only I could find an FM to R. ;p

DanL

On Sat, 7 Oct 2000, Erik Paulson wrote:

> Many sysadmins (myself included) get very nervous when users ask for a suid
> helper.

Me too. I produced a patch which makes the (old) Ethertap interface obey
the permissions on the device node, which means all that needs to be done
with root permission is ifconfig tap$n ; chown $user /dev/tap$n

It should be in the list archives, for both 2.2 and 2.4 kernels. Making
UML work with it is left as an exercise for the reader.

-- 
dwmw2

On Sun, Oct 08, 2000 at 12:35:48AM -0500, Jeff Dike wrote:
> I've been waiting for someone to send me that stack.  There aren't any real 
> smoking guns there.  I'm guessing that the difference between your laptop and 
> the machine it works on is that your laptop is running a fairly recent kernel 
> (2.4.0-testx) and the other isn't.

Yep, that's right.

> The sigcontext struct greatly increased in 
> size (to ~800 bytes IIRC) to accomodate the MMX registers or something.  There 
> are three signals on your stack, so those frames by themselves are taking up 
> half the stack page.
> 
> Anyway, the patch below removes 256 bytes from the set_signals frame.  It 
> ought to alleviate things a bit.  I'll be looking for other things I can do, 
> as well. Let me know how it works for you.

I'm afraid this doesn't help.  The stack still overflows at the same point.
It looks like each signal frame is ~760 bytes.  Even with this patch, the
overflow is 808 bytes (without the patch it's 1232 bytes).

	J

Thank you!

I've been waiting for someone to send me that stack.  There aren't any real 
smoking guns there.  I'm guessing that the difference between your laptop and 
the machine it works on is that your laptop is running a fairly recent kernel 
(2.4.0-testx) and the other isn't.  The sigcontext struct greatly increased in 
size (to ~800 bytes IIRC) to accomodate the MMX registers or something.  There 
are three signals on your stack, so those frames by themselves are taking up 
half the stack page.

Anyway, the patch below removes 256 bytes from the set_signals frame.  It 
ought to alleviate things a bit.  I'll be looking for other things I can do, 
as well. Let me know how it works for you.

				Jeff

--- arch/um/kernel/signal_user.c~       Thu Sep 14 17:00:08 2000
+++ arch/um/kernel/signal_user.c        Sun Oct  8 00:21:29 2000
@@ -45,26 +45,29 @@
 
 int set_signals(int enable)
 {
-       sigset_t mask, unmask, old;
+       sigset_t mask;
+       int ret;
 
        check_stack_overflow(&enable);
+       sigprocmask(SIG_BLOCK, NULL, &mask);
+       ret = enable_mask(&mask);
        sigemptyset(&mask);
-       sigemptyset(&unmask);
-       if(enable & (1 << SIGIO_BIT)) sigaddset(&unmask, SIGIO);
-       else sigaddset(&mask, SIGIO);
+       if(enable & (1 << SIGIO_BIT)) sigaddset(&mask, SIGIO);
        if(enable & (1 << SIGVTALRM_BIT)){
-               sigaddset(&unmask, SIGVTALRM);
-               sigaddset(&unmask, SIGALRM);
+               sigaddset(&mask, SIGVTALRM);
+               sigaddset(&mask, SIGALRM);
        }
-       else {
+       if(sigprocmask(SIG_UNBLOCK, &mask, NULL) < 0)
+               panic("Failed to enable signals");
+       sigemptyset(&mask);
+       if((enable & (1 << SIGIO_BIT)) == 0) sigaddset(&mask, SIGIO);
+       if((enable & (1 << SIGVTALRM_BIT)) == 0){
                sigaddset(&mask, SIGVTALRM);
                sigaddset(&mask, SIGALRM);
        }
-       if(sigprocmask(SIG_BLOCK, &mask, &old) < 0)
-               panic("Failed to change signal mask");
-       if(sigprocmask(SIG_UNBLOCK, &unmask, NULL) < 0)
-               panic("Failed to change signal mask");
-       return(enable_mask(&old));
+       if(sigprocmask(SIG_BLOCK, &mask, NULL) < 0)
+               panic("Failed to block signals");
+       return(ret);
 }
 
 /*

epa...@up... said:
> Many sysadmins (myself included) get very nervous when users ask for a
> suid helper. 

There's another possibility.  The eth daemon can be made to communicate with 
its peers on other boxes (which is a good idea in its own right), and you 
could set up a virtual network that has non-privileged daemons, except for one 
running as root on a machine that no one cares about.  That one would be the 
gateway to the outside world for all the others.

I think that most sysadmins would have no trouble finding an old box that 
could be dedicated as the UML gateway.  If it got rooted through the eth 
daemon, that doesn't pose any danger to anything else.

				Jeff

epa...@up... said:
> for many apps simply proxying at the socket level from the UML kernel
> to the host  kernel would be completely sufficent - imagine someone
> running a sandboxed app, or (when UML gets ported to say FreeBSD)
> running a Linux app that opens  a non-priviliged socket up to the
> network. There doesn't seem to be any  theoretical reason why that
> shouldn't be possible.

Can a socket be made to look enough like a real network interface to be useful?
All network proggies do the bind/listen/accept/connect thing, which sends you 
into the network layer.  At the device layer all you see are packets which 
need to be sent off somewhere.  I don't see how those can be sent to a socket 
- they need to be sent via a device in the host.

So a device driver doesn't seem like it would work.  Are there other layers in 
the network subsystem that have the hooks to plug something else in that would 
work?

It would be nice to drop the suid helper, but I don't see a way to do it.

				Jeff

On Fri, Oct 06, 2000 at 06:12:26PM -0500, Jeff Dike wrote:
> ma...@co... said:
> > Is there any way to setup networking without running UML as root? 
> 
> UML can be running as a normal user, but you do need a suid helper.  With the 
> umn device, just put a suid root ifconfig somewhere in your path.
> 
> With the eth device, you run um_eth_net_util as root if you want access to the 
> host networking.  If you only want to network UMLs, then that doesn't even 
> need to run as root.

This requirement of even having a suid is kind of a bummer - for many
apps simply proxying at the socket level from the UML kernel to the host 
kernel would be completely sufficent - imagine someone running a sandboxed
app, or (when UML gets ported to say FreeBSD) running a Linux app that opens 
a non-priviliged socket up to the network. There doesn't seem to be any 
theoretical reason why that shouldn't be possible.

Many sysadmins (myself included) get very nervous when users ask for a suid
helper.

-Erik

> 
> 				Jeff
> 
> 
> _______________________________________________
> User-mode-linux-user mailing list
> Use...@li...
> http://lists.sourceforge.net/mailman/listinfo/user-mode-linux-user

ma...@co... said:
> Failed to set slip line discipline - errno = 1 

Oh yeah, I forgot about that one.

Some time after 2.2.5 (which is what I'm running) someone tightened up the 
security on slip so that you need to be root in order to set the slip line 
discipline on a tty.  For later 2.2 kernels, um_ifconfig isn't enough.  The 
suid helper also needs to take the fd to the tty from uml and set up slip on 
it.

				Jeff

Jeff Dike wrote:

> With the eth device, you run um_eth_net_util as root if you want access to the
> host networking.  If you only want to network UMLs, then that doesn't even
> need to run as root.

Finally, I got this working!  Now I've got a non-root UML running, with
access to the rest of my network.  Thanks for the help.

 - Matt

Jeff Dike wrote:

> UML can be running as a normal user, but you do need a suid helper.  With the
> umn device, just put a suid root ifconfig somewhere in your path.

I've tried making a suid copy of ifconfig in my path on my host system,
called um_ifconfig, which runs when I use ifconfig in UML.  It doesn't
fix the problem though.  Here's what I get (if running UML as root, this
same setup works just fine):

Going multiuser...
Configuring eth0 as 10.0.0.101...
Failed to set slip line discipline - errno = 1
Couldn't set slip encapsulation - errno = 22
SIOCSIFADDR: No such device
sl-1: unknown interface: No such device
SIOCSIFDSTADDR: No such device
sl-1: unknown interface: No such device
sl-1: unknown interface: No such device
um_ifconfig failed
SIOCSIFHWADDR: Operation not permitted
Failed to initialize network!
Activating IPv4 packet
forwarding...                                                                                            

> With the eth device, you run um_eth_net_util as root if you want access to the
> host networking.  If you only want to network UMLs, then that doesn't even
> need to run as root.

I'll give this a try, thanks.

 - Matt

ma...@co... said:
> Is there any way to setup networking without running UML as root? 

UML can be running as a normal user, but you do need a suid helper.  With the 
umn device, just put a suid root ifconfig somewhere in your path.

With the eth device, you run um_eth_net_util as root if you want access to the 
host networking.  If you only want to network UMLs, then that doesn't even 
need to run as root.

				Jeff

James MacLean wrote:

> > > Just ran umn this AM with 2.2.18pre11 as the slip physical host. Worked
> > > just fine. I could contact physical, local subnet and remote machines.

> > Are you running UML as a non-root user when using umn?  I am trying to
> > do so, but have only had success when running UML as root.

> Yes. All testing to date is being done as root.

Is there any way to setup networking without running UML as root?

 - Matt

On Fri, 6 Oct 2000, Matt Clay wrote:
> James MacLean wrote:
> > Just ran umn this AM with 2.2.18pre11 as the slip physical host. Worked
> > just fine. I could contact physical, local subnet and remote machines.
> Are you running UML as a non-root user when using umn?  I am trying to
> do so, but have only had success when running UML as root.

Yes. All testing to date is being done as root.
 
>  - Matt

JES
--
James B. MacLean        mac...@ed...
Department of Education http://www.ednet.ns.ca/~macleajb
Nova Scotia, Canada
B3M 4B2
     

On Fri, 6 Oct 2000, Jeff Dike wrote:
> mac...@ed... said:
> > Just ran umn this AM with 2.2.18pre11 as the slip physical host.
> > Worked just fine. I could contact physical, local subnet and remote
> > machines.
> > Tried um_eth_net again but still same problem. It can not ping
> > physical, can ping local subnet (and be connected to from same), and
> > can not ping remote networks. 
> So the difference is between the umn and eth devices.

Yes. And it only shows up on my home p166 machine.
 
> Can you show exactly how you're doing the eth setup?

A script does this to start up:

killall um_eth_net_util
sleep 1
echo Starting UML Network Device on ETH0
./um_eth_net_util eth0 100
echo Starting Linux
./linux

That inside linux does:

ifconfig eth0 hw ether 0:0:10:2:4:1
ifconfig eth0 192.168.0.241 netmask 255.255.255.0
etc...

> 				Jeff

Is that what you were looking for?
JES
--
James B. MacLean        mac...@ed...
Department of Education http://www.ednet.ns.ca/~macleajb
Nova Scotia, Canada
B3M 4B2
     

James MacLean wrote:

> Just ran umn this AM with 2.2.18pre11 as the slip physical host. Worked
> just fine. I could contact physical, local subnet and remote machines.

Are you running UML as a non-root user when using umn?  I am trying to
do so, but have only had success when running UML as root.

 - Matt

I've been attempting to setup networking using the slip-based umn
device.  It works perfectly when running UML as root, but I have been
unable to make it work as a regular user.

I've setup "um_ifconfig" as a setuid root version of "ifconfig", but
this doesn't fix the problem.  The problem appears to be the attempt to
setup slip line discipline, which returns errno 1 (operation not
permitted).  Here is a snippet of the boot process, and what happens
when I try to setup the network:

Going multiuser...
Configuring eth0 as 10.0.0.101...
Failed to set slip line discipline - errno = 1
Failed to set O_ASYNC and O_NONBLOCK on fd # -1, errno = 9
umn_init : request_irq failed - errno = -1
SIOCSIFFLAGS: Operation not permitted
SIOCSIFADDR: No such device
sl0: unknown interface: No such device
SIOCSIFDSTADDR: No such device
sl0: unknown interface: No such device
sl0: unknown interface: No such device
um_ifconfig failed
SIOCSIFHWADDR: Operation not permitted
SIOCSIFFLAGS: Device not configured
SIOCADDRT: Network is unreachable
Activating IPv4 packet forwarding...

It appears that a non-root user does not have permission for the ioctl
calls necessary to setup the slip link.  Am I doing something wrong?  Is
there a way to fix this?

My host system is Slackware Linux 7.0 running the 2.2.16 kernel.  I'm
using UML 2.4.0-test9 with Slackware 7.1.  If you need more information,
I'll be glad to provide it.  Any help (or alternatives to non-root
networking) are greatly appreciated.

 - Matt Clay
 - ma...@co...
 - Cowboyz.com

I looked into this a bit, and I found that devfs is putting a 3K structure on 
the stack, which seems bad to me.  I complained at Richard Gooch about it.

In the meantime, if you're seeing this problem (especially at boot time) apply 
the patch below.

There is still a problem with interrupts causing stack overflows which I'm 
trying to track down, but this patch provides some extra room for people who 
aren't triggering that bug.

				Jeff

--- arch/um/kernel/process_kern.c~      Mon Sep 25 15:34:25 2000
+++ arch/um/kernel/process_kern.c       Fri Oct  6 12:07:28 2000
@@ -711,8 +711,13 @@
 
 void check_stack_overflow(void *ptr)
 {
-       if((((unsigned long) ptr) & PAGE_MASK) == (unsigned long) current)
-               panic("Stack overflowed onto current_task page");
+       unsigned long addr, c;
+
+       addr = (unsigned long) ptr;
+       c = (unsigned long) current;
+
+       if(addr - c < PAGE_SIZE / 2)
+               panic("Stack overflowed well into the current_task page");
 }
 
 int singlestepping(void *t)

mac...@ed... said:
> Just ran umn this AM with 2.2.18pre11 as the slip physical host.
> Worked just fine. I could contact physical, local subnet and remote
> machines.

> Tried um_eth_net again but still same problem. It can not ping
> physical, can ping local subnet (and be connected to from same), and
> can not ping remote networks. 

So the difference is between the umn and eth devices.

Can you show exactly how you're doing the eth setup?

				Jeff

Hi Jeff et al,

Just ran umn this AM with 2.2.18pre11 as the slip physical host. Worked
just fine. I could contact physical, local subnet and remote machines.

Tried um_eth_net again but still same problem. It can not ping physical,
can ping local subnet (and be connected to from same), and can not ping
remote networks.

JES
--
James B. MacLean        mac...@ed...
Department of Education http://www.ednet.ns.ca/~macleajb
Nova Scotia, Canada
B3M 4B2
     

On Thu, 5 Oct 2000, Jeff Dike wrote:
> mac...@ED... said:
> > In a directory I have a small root filesystem that was basically a
> > boot disk with vi and ping added and some extra space to see if I
> > could get apache on it :). 
> That makes it a little tough to reproduce it by doing exactly what you're 
> doing.

I can make the rootfs available if that would help, but I doubt it would
:(.
 
> > You mean the umn method? Not from home because I did not have slip in
> > the kernel.
> Could that be the difference between home and work?

Sorry on my explaination. I am using um_eth_net_util at both sites.

> slip is available as a module, so getting the umn device working shouldn't be 
> hard.

I need it for my weird kernel, so I'll just have to compile one...

Also, in a uml, um_eth_net_set says permission denied for /dev/ram0. Or
atleast thats what I remember it saying :). But I figure I am just not
booting things as I should :(.

Later,
JES
--
James B. MacLean        mac...@ed...
Department of Education http://www.ednet.ns.ca/~macleajb
Nova Scotia, Canada
B3M 4B2
     
um_eth_net_set

mac...@ED... said:
> Yes, the password is hard to tell if you get a character or not :(. 

I could see how that would really blow :-)

> In a directory I have a small root filesystem that was basically a
> boot disk with vi and ping added and some extra space to see if I
> could get apache on it :). 

That makes it a little tough to reproduce it by doing exactly what you're 
doing.

> You mean the umn method? Not from home because I did not have slip in
> the kernel.

Could that be the difference between home and work?

slip is available as a module, so getting the umn device working shouldn't be 
hard.

				Jeff