Re: Sysctl and root privileges, how could I avoid them ?
JINMEI Tatuya / $B?@L@C#:H(B escribió: > > > On Fri, 29 Nov 2002 18:17:57 +0100, > > Juan Francisco Rodriguez Hervella <[EMAIL PROTECTED]> said: > > > I'm implementing a modification in the > > file "getaddrinfo.c", which calls a sysctlbyname > > function, but the problem is that > > this sysctlbyname function call requires "root" privileges. > > > But I can not expect all the programs linked to > > libinet6 (where getaddrinfo is used) to be executed as root ! > > Perhaps your code tries the write operation of sysctl, in which case > the super user privilege is required by default. If your goal can be > achieved without a write operation, the easiest way would be to just > avoid the write. If you really need a write operation for every user, > you may probably have to reconsider the library design. Since sysctl > tends to affect fundamental behavior of kernel, the required privilege > is basically reasonable and should not be overridden as an easy > compromise. > Are you talking about the flag CTLFLAG_RW ? I'm using req->oldptr == NULL and req->newptr != NULL to add a new element into a kernel table and I plan to use req->oldptr & req->newptr != NULL to show the elements of the table... could I instead use CTLFLAG_RO and keep the same access to the buffers ? Excuse me because it might be a foolish question, but I don't know how these flags can affect the behaviour of the sysctl operations... Anyway, I'm going to try different options today :) Thanks! -- JFRH. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: Multihoming - implementing RFC 1122
Helge Oldach escribió: > > All, > > I wonder whether there are plans to complete implementation of the > "strong ES" model as described in RFC 1122 for multihoming hosts on > FreeBSD. Essentially this would assure that a multihomed host would > send and receive IP packets through the "correct" interface (that is, > the physical interface that is configured with the IP address used in > the packets). > I don't like the strong ES model. IMHO, with weak ES model we can obtain the best of multihoming benefits. the strong ES model makes use of source routing, which might forbid the communication where it could be possible. I don't see why a host should discard a packet for him, only because it has arrived at other interface. -- JFRH. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: Sysctl and root privileges, how could I avoid them ?
Hi: I'm thinking in implement a new system call to make my stuff... is it very difficult ? Could you point me to any guide/boot/whatever to learn about it ? Thanks again. JINMEI Tatuya / $B?@L@C#:H(B escribió: > > > On Fri, 29 Nov 2002 18:17:57 +0100, > > Juan Francisco Rodriguez Hervella <[EMAIL PROTECTED]> said: > > > I'm implementing a modification in the > > file "getaddrinfo.c", which calls a sysctlbyname > > function, but the problem is that > > this sysctlbyname function call requires "root" privileges. > > > But I can not expect all the programs linked to > > libinet6 (where getaddrinfo is used) to be executed as root ! > > Perhaps your code tries the write operation of sysctl, in which case > the super user privilege is required by default. If your goal can be > achieved without a write operation, the easiest way would be to just > avoid the write. If you really need a write operation for every user, > you may probably have to reconsider the library design. Since sysctl > tends to affect fundamental behavior of kernel, the required privilege > is basically reasonable and should not be overridden as an easy > compromise. > > JINMEI, Tatuya > Communication Platform Lab. > Corporate R&D Center, Toshiba Corp. > [EMAIL PROTECTED] > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-net" in the body of the message -- JFRH. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Any how-to/online book/guide to implement a new system call in FreeBSD ?
Thanks. -- JFRH. To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: Multihoming - implementing RFC 1122
On Mon, 02 Dec 2002, Juan Francisco Rodriguez Hervella wrote: > Helge Oldach escribió: > > > > All, > > > > I wonder whether there are plans to complete implementation of the > > "strong ES" model as described in RFC 1122 for multihoming hosts on > > FreeBSD. Essentially this would assure that a multihomed host would > > send and receive IP packets through the "correct" interface (that is, > > the physical interface that is configured with the IP address used in > > the packets). > > > > I don't like the strong ES model. IMHO, with weak ES model we can > obtain the best of multihoming benefits. the strong ES model > makes use of source routing, which might forbid the communication > where it could be possible. > > I don't see why a host should discard a packet for him, only > because it has arrived at other interface. I see good reasons indeed. For example when I bind a daemon on a given IP, I have sometimes good reasons to have the multihomed host discard packets coming from the 'wrong' interface. As long as the model (strong vs weak) is tunable via a sysctl (as it is already with net.inet.ip.check_interface), I think that this is the perfect behavior: I can select whatever fits best my needs in a given situation. Cheers, - yann To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: Multihoming - implementing RFC 1122
Juan Francisco Rodriguez Hervella: > Helge Oldach escribió: > > I wonder whether there are plans to complete implementation of the > > "strong ES" model as described in RFC 1122 for multihoming hosts on > > FreeBSD. Essentially this would assure that a multihomed host would > > send and receive IP packets through the "correct" interface (that is, > > the physical interface that is configured with the IP address used in > > the packets). > I don't like the strong ES model. Then, don't use it. I am not asking to modify the default behaviour, I am just asking for extra functionality that you may use or not. > the strong ES model > makes use of source routing, You are mixing up source routing and policy routing. > I don't see why a host should discard a packet for him, only > because it has arrived at other interface. Anti-spoofing policies, for example. Helge To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
fh
Thanks, Tim Kientzle, but i still need one "c code" to add to
autoconf.c, and gets a NFS file handle to my root directory. We have
the solution (diskless) with dhcp/bootp... but we do not want this
anymore, due the things that i have sad before. Thanks.
All that i need, is that c code... :)
In vfs_syscalls.c i have found this "code":
---
/*
* Get (NFS) file handle
*/
#ifndef _SYS_SYSPROTO_H_
struct getfh_args {
char*fname;
fhandle_t *fhp;
};
#endif
int
getfh(p, uap)
struct proc *p;
register struct getfh_args *uap;
{
struct nameidata nd;
fhandle_t fh;
register struct vnode *vp;
int error;
/*
* Must be super user
*/
error = suser(p);
if (error)
return (error);
NDINIT(&nd, LOOKUP, FOLLOW | LOCKLEAF, UIO_USERSPACE, uap->fname,
p);
error = namei(&nd);
if (error)
return (error);
NDFREE(&nd, NDF_ONLY_PNBUF);
vp = nd.ni_vp;
bzero(&fh, sizeof(fh));
fh.fh_fsid = vp->v_mount->mnt_stat.f_fsid;
error = VFS_VPTOFH(vp, &fh.fh_fid);
vput(vp);
if (error)
return (error);
error = copyout(&fh, uap->fhp, sizeof (fh));
return (error);
}
---
Can i adapt it for my porpouses?
I need help, and i guess that here is the place... :)
Somebody can help?
[EMAIL PROTECTED]
SDF Public Access UNIX System - http://sdf.lonestar.org
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-net" in the body of the message
SO_DONTROUTE, arp's, ipfw fwd, etc
I have a setup where I have a transparent proxy using ipfw fwd (to localhost). Data is sent to this device using a MAC rewrite so that packets arrive with my MAC, but the original source and destination IP. When I receive the SYN, i accept the connection, which causes an ARP to be emitted for the source address, and then the SYN/ACK. Now, I would like to have my default route not be on the 'data' interface which has the ipfw rule. It seems like this would work if: a) the MAC address for the source address (the router which sent me the packet) was entered into the ARP cache automatically when the SYN was received. b) I used SO_DONTROUTE in my proxy application. Does anybody have any comments on that? Is there a reason that learning ARP entries isn't done passively? I assume that since the receive interface is cached in the syncache, and then proxied through to the PCB, that the SO_DONTROUTE will cause the return packets to go back through that same interface? Is there a simpler way? --don ([EMAIL PROTECTED] www.sandvine.com) To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: Multihoming - implementing RFC 1122
Juan Francisco Rodriguez Hervella wrote: I don't like the strong ES model. IMHO, with weak ES model we can obtain the best of multihoming benefits. the strong ES model makes use of source routing, which might forbid the communication where it could be possible. I don't see why a host should discard a packet for him, only because it has arrived at other interface. Layer 2 protocols do. Layer 3 has traditionally followed the weak host model, while layer 2 protocols usually follow the strong host model. Having the option of enabling strong host for layer 3 is beneficial for layer 3 VPNs, where IP is used as both link and network protocol. Lars -- Lars Eggert <[EMAIL PROTECTED]> USC Information Sciences Institute smime.p7s Description: S/MIME Cryptographic Signature
bge driver problems
Hello I have been trying to get the 3Com 996 BT gigabit network interface (bge) to work on FreeBSD 4.3 Release. I got the driver from : http://www.freebsd.org/~wpaul/Broadcom/4.x/bcm570x_drv.tar.gz I have two machines with the interfaces connected via a crossover cable and have not been able to make the devices talk to each other. They work under Linux without problem. The dmesg is attached and so is the kernel configuration and the ifconfig message. I use a modified kernel so cannot upgrade to the Stable or 4.[4-7]. It would be a big help if you could provide more information about how to get these drivers to work. I was following some discussion on the buggy card on this list - I hope things have improved since then. Please cc me on the message as I am not subscribed to this list. Thanks Aniruddha bge0: flags=8802 mtu 1500 ether 00:04:76:dd:2e:bb media: autoselect (100baseTX ) status: active supported media: autoselect 100baseTX 100baseTX 10baseT/UTP 10baseT/UTP none autoselect 100baseTX 100baseTX 10baseT/UTP 10baseT/UTP none autoselect 100baseTX 100baseTX 10baseT/UTP 10baseT/UTP none autoselect 100baseTX 100baseTX 10baseT/UTP 10baseT/UTP none autoselect 100baseTX 100baseTX 10baseT/UTP 10baseT/UTP none autoselect 100baseTX 100baseTX 10baseT/UTP 10baseT/UTP none autoselect 100baseTX 100baseTX 10baseT/UTP 10baseT/UTP none autoselect 100baseTX 100baseTX 10baseT/UTP 10baseT/UTP none autoselect 100baseTX 100baseTX 10baseT/UTP 10baseT/UTP none autoselect 100baseTX 100baseTX 10baseT/UTP 10baseT/UTP none autoselect 100baseTX 100baseTX 10baseT/UTP 10baseT/UTP none autoselect 100baseTX 100baseTX 10baseT/UTP 10baseT/UTP none autoselect 100baseTX 100baseTX 10baseT/UTP 10baseT/UTP none autoselect 100baseTX 100baseTX 10baseT/UTP 10baseT/UTP none autoselect 100baseTX 100baseTX 10baseT/UTP 10baseT/UTP none autoselect 100baseTX 100baseTX 10baseT/UTP 10baseT/UTP none autoselect 100baseTX 100baseTX 10baseT/UTP 10baseT/UTP none autoselect 100baseTX 100baseTX 10baseT/UTP 10baseT/UTP none autoselect 100baseTX 100baseTX 10baseT/UTP 10baseT/UTP none autoselect 100baseTX 100baseTX 10baseT/UTP 10baseT/UTP none autoselect 100baseTX 100baseTX 10baseT/UTP 10baseT/UTP none autoselect 100baseTX 100baseTX 10baseT/UTP 10baseT/UTP none autoselect 100baseTX 100baseTX 10baseT/UTP 10baseT/UTP none autoselect 100baseTX 100baseTX 10baseT/UTP 10baseT/UTP none autoselect 100baseTX 100baseTX 10baseT/UTP 10baseT/UTP none autoselect 100baseTX 100baseTX 10baseT/UTP 10baseT/UTP none autoselect 100baseTX 100baseTX 10baseT/UTP 10baseT/UTP none autoselect 100baseTX 100baseTX 10baseT/UTP 10baseT/UTP none autoselect 100baseTX 100baseTX 10baseT/UTP 10baseT/UTP none autoselect 100baseTX 100baseTX 10baseT/UTP 10baseT/UTP none autoselect 100baseTX 100baseTX 10baseT/UTP 10baseT/UTP none 100baseTX 100baseTX none bge1: flags=8843 mtu 1500 inet 10.10.10.10 netmask 0xff00 broadcast 10.10.10.255 ether 00:04:76:df:ce:58 media: autoselect (none) status: no carrier supported media: autoselect 100baseTX 100baseTX 10baseT/UTP 10baseT/UTP none autoselect 100baseTX 100baseTX 10baseT/UTP 10baseT/UTP none autoselect 100baseTX 100baseTX 10baseT/UTP 10baseT/UTP none autoselect 100baseTX 100baseTX 10baseT/UTP 10baseT/UTP none autoselect 100baseTX 100baseTX 10baseT/UTP 10baseT/UTP none autoselect 100baseTX 100baseTX 10baseT/UTP 10baseT/UTP none autoselect 100baseTX 100baseTX 10baseT/UTP 10baseT/UTP none autoselect 100baseTX 100baseTX 10baseT/UTP 10baseT/UTP none autoselect 100baseTX 100baseTX 10baseT/UTP 10baseT/UTP none autoselect 100baseTX 100baseTX 10baseT/UTP 10baseT/UTP none autoselect 100baseTX 100baseTX 10baseT/UTP 10baseT/UTP none autoselect 100baseTX 100baseTX 10baseT/UTP 10baseT/UTP none autoselect 100baseTX 100baseTX 10baseT/UTP 10baseT/UTP none autoselect 100baseTX 100baseTX 10baseT/UTP 10baseT/UTP none autoselect 100baseTX 100baseTX 10baseT/UTP 10baseT/UTP none autoselect 100baseTX 100baseTX 10baseT/UTP 10baseT/UTP none autoselect 100baseTX 100baseTX 10baseT/UTP 10baseT/UTP none autoselect 100baseTX 100baseTX 10baseT/UTP 10baseT/UTP none autoselect 100baseTX 100baseTX 10baseT/UTP 10baseT/UTP none autoselect 100baseTX 100baseTX 10baseT/UTP 10baseT/UTP none autoselect 100baseTX 100baseTX 10baseT/UTP 10baseT/UTP none autoselect 100baseTX 100baseTX 10baseT/UTP 10baseT/UTP none autoselect 100baseTX 100baseTX 10baseT/UTP 10baseT/UTP none autoselect 100baseTX 100baseTX 10baseT/UTP 10baseT/UTP none autoselect 100baseTX 100baseTX 10baseT/UTP 10baseT/UTP none autoselect 100baseTX 100baseTX 10baseT/UTP 10baseT/UTP none autoselect 100baseTX 100baseTX 10baseT/UTP 10baseT/UTP none autoselect 100baseTX 100baseTX 10baseT/UTP 10baseT/UTP none autoselect 100baseTX 100baseTX 10baseT/UTP 10baseT/UTP none autoselect 100baseTX
Redundant NIC/Connections
I was wondering how people are handling redundant connections? We would like to have dual NICs in the FreeBSD box with each NIC connected to a different switch. Both switches are in the same broadcast domain. In pointers, hints on this may done would be greatly appreciated. DaveD To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
Re: DNAT on freebsd
Hi, All. Please note that natd supports the proxy_rule command which enables some of this functionality. The only issues is the missing UDP support (which I have patches for locally) and the lack of rewriting urls embedded in packets. Best regards, Nicolai Petri On Friday 29 November 2002 13:47, Andre Oppermann wrote: > Nerijus Bendziunas wrote: > > Hi, > > i need to do something like DNAT in iptables on freebsd. > > I mean to rewrite packets which match some rule dst ip/port. > > ie: all smtp traffic (any 25) redirect to some ip 25. or if user tries > > to connect to www.yahoo.com:80 i rewrite dst and he realy connects to > > www.google.lt:80 or smth. > > We have written one which can do that: > > http://diehard.n-r-g.com/stuff/freebsd/ To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-net" in the body of the message
