Im trying to set up qemu to use tun/tap networking. If I call qemu with sudo, no problem. If I call qemu without sudo, as user andrew (member of admin group) i get the following error message:

Could not configure '/dev/rtc' to have a 1024 Hz timer. This is not a fatal
error, but for better emulation accuracy either use a 2.6 host Linux kernel or
type 'echo 1024 > /proc/sys/dev/rtc/max-user-freq' as root.
warning: could not configure /dev/net/tun: no virtual network emulation
Could not initialize device 'tap'

My /etc/sudoers file:
...
#changed to let qemu give net address without sudo 20061018
Cmnd_Alias QEMU=/sbin/ifconfig, /usr/sbin/brctl
# Defaults
Defaults !lecture,tty_tickets,!fqdn
# User privilege specification
root ALL=(ALL) ALL
# Members of the admin group may gain root privileges
%admin ALL=(ALL) ALL
#changed to let qemu give net address without sudo 20061018
andrew ALL=NOPASSWD:QEMU

my /etc/network/interfaces
auto lo
iface lo inet loopback
auto eth0
#qemu version
auto br0
iface br0 inet static
address 192.168.1.101
network 192.168.1.0
netmask 255.255.255.0
broadcast 192.168.1.255
gateway 192.168.1.22
bridge_ports eth0
bridge_fd 1
bridge_hello 1
bridge_stp off

to test, I typed
sudo brctl addbr br1
sudo ifconfig br1 192.168.1.40

these two commands complete sucessfully, they dont require the password.

crwxrwx--- 1 root root 10, 200 2006-05-31 03:15 /dev/net/tun
I even tried 777...

-rwxr-xr-x 1 root root 195 2006-10-18 21:27 /etc/qemu-ifup
/etc/qemu-ifup is:
echo "Executing /etc/qemu-ifup"
echo "Bringing up $1 for bridged mode..."
sudo /sbin/ifconfig $1 0.0.0.0 promisc up
echo "Adding $1 to br0..."
sudo /usr/sbin/brctl addif br0 $1
sleep 2

So, my question is, why does qemu start properly only when called using sudo, and what do I need to do to be able to call qemu without being root or using sudo and have tun/tap networking work?

I had exactly same problem after updating kernel to 2.6.18. Looks like some kernel developers don't understand group based access control... The problem is caused by this change, and reverting that + recompiling the kernel fixes it. There is another possible solution too.

The Right Way is to have a special qemu group for this purpose, permissions 660 root.qemu for the device and 750 root.qemu for the script.

Another tip: I use NAT instead of bridging. That way the guest OS loses its network connection if host system's firewall is down, so it cannot be accidentally left without protection. It may be a bit more work to set up, but still easier than cleaning up a Windows guest after such accident...

Thanks! I needed a fast solution for testing so I opted to just get it going on vmware server. Ill try in the next days your suggestions. You're right about nat, I specificaly wanted to test a debian machine wide open, so chose the tun/tap solution.