Jail Pseudo Terminals
Hi All, Just a quick question Im hoping someone can help me with. I extended the number of pty's available on my base box just fine, with an edit to /etc/ttys and making some new devices, then just a kill -1 1, and everything worked fine. I did exactly the same thing under the jail, it didnt work, rebooted the box and it still didnt work, does anyone know how to extend the number of pty's under a jail? Any help would be MUCH appreciated Thanks Andrew To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Jail Pseudo Terminals
Hi, Ok this is getting a bit strange. Interestingly enough ssh works 100% with my method of tty creation, having created (from outside the jail) ttyp32 - ttyp100 (with the minor/major numbers set as 5,XX where XX is ttypXX), and a mknod type of c, ssh allocates ttys fine, however screen still tells me there are no ttys available? Any ideas? Andrew On Mon, 12 Feb 2001, Robert Watson wrote: > > On Mon, 12 Feb 2001, Lists Account wrote: > > > Just a quick question Im hoping someone can help me with. I extended > > the number of pty's available on my base box just fine, with an edit to > > /etc/ttys and making some new devices, then just a kill -1 1, and > > everything worked fine. > > > > I did exactly the same thing under the jail, it didnt work, rebooted the > > box and it still didnt work, does anyone know how to extend the number > > of pty's under a jail? Any help would be MUCH appreciated > > Hmm. What do you mean by, ``I did exactly the same thing under the jail'' > -- the mknod() syscall for device nodes is unavailable under jail() so as > to prevent the creation of inappropriate devices that might allow the > attacker to circumvent the jail() protections. So there are two things > you could have done: (1) used MAKEDEV under jail(), and either it didn't > generate appropriate error messages, or you missed them, and you should be > running the MAKEDEV in the per-jail /dev directory, but not from within > the jail(), or (2) you ran MAKEDEV outside the jail, and something else is > broken. My first guess would be that you did (1), and running MAKEDEV > outside of a jail() process but in the jail() /dev will fix things. > > Also, generally speaking, pty's are not managed by init, rather, they are > dynamically allocated using openpty(), so you shouldn't need to HUP init, > or even modify /etc/ttys. In fact, from within a jail(), you should be > unable to successfully HUP the pid 1 init process. > > Robert N M Watson FreeBSD Core Team, TrustedBSD Project > [EMAIL PROTECTED] NAI Labs, Safeport Network Services > > > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Jail Pseudo Terminals
Interesting things Ive found with this, thought someone on the list might
eventually have a similar problem to what I had, so here is the fix:
(Interestingly enough this was _NOT_ nessasary under jail)
In screen's config.h the following exists:
/*
* If your system has the new format /etc/ttys (like 4.3 BSD) and the
* getttyent(3) library functions, define GETTTYENT.
*/
#define GETTTYENT 1
if you change that to #define GETTTYENT 0 (I.E you undefine the option) it
works 100% and will give you all your new terminals.
As a matter of interest, if anyone here can explain to me why this fixed
my problem, or perhaps let me know if there is a problem with
getttyent() under jail it would be much appreciated.
Thanks
Andrew Alston
On Tue, 13 Feb 2001, Neil Blakey-Milner wrote:
> On Tue 2001-02-13 (07:09), Lists Account wrote:
> > Ok this is getting a bit strange. Interestingly enough ssh works 100%
> > with my method of tty creation, having created (from outside the
> > jail) ttyp32 - ttyp100 (with the minor/major numbers set as 5,XX where XX
> > is ttypXX), and a mknod type of c, ssh allocates ttys fine, however screen
> > still tells me there are no ttys available?
> >
> > Any ideas?
>
> Recompile screen with the extra devices present - it uses some really
> interesting system to work out what devices to use, and it will limit
> you to ttyp*, and not tty{q,r,s,P,Q,R,S}*, if the latter aren't
> present.
>
> Neil
> --
> Neil Blakey-Milner
> [EMAIL PROTECTED]
>
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
gcc -pthread / segfault problem
Hi all, I was coding some stuff under a 4.2 box of mine here earlier today and I seem to have hit a very strange bug, I was wondering if anyone could help me out here. I wrote a bunch of pthread enabled code, when I tried to run the program, after I compiled it with -pthread (I had to with the threading code in there), it segfaulted, so I ran it through gdb, and it was segfaulting on malloc(). So I dug around some more, and eventually I tried changing that single line to a c++ new() call, no more problems... So for the sake of testing, I commented out all the code that needed pthreads, and compiled it again, without the -pthread flag, unchanged except for a function that I commented out, with the original malloc() call, no problems again. Then, with that function commented out, exactly was I had compiled it a few seconds earlier where it worked, I recompiled it, using the -pthread flag again, ran it, and sure enough it segfaults on the first malloc() it reaches. Is there a bug in the pthreads, or have I possibly missed something in the code that I need in there to make it work with -pthread? Any help or suggestions would be MUCH appreciated Thanks Andrew Alston To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
PCI -> PCMCIA Bridge Adapter
Hi All, I just was wondering if anyone out there knew of any drivers that support the pccard PCI -> PCMCIA bridge adapter, also made by pccard (see www.pccard.co.uk), similar to the ISA -> PCMICIA bridge adapter that is currently supported under FreeBSD If anyone knows of such a driver please let me know, any help on this one would be much appreciated Many Thanks Andrew To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: PCI -> PCMCIA Bridge Adapter
Hi All pcic-pci1: at device 16.1 on pci0 pcic-pci1: TI12XX PCI Config Reg: [pwr save][pci only] Just to say, I seem to have fbsd recognizing my pci cardbus bridge in 4.3-RELEASE however, it doesnt pick up the orinoco card plugged into there, is this because of bugs mentioned on the list so far or is this for another reason? Thanks Andrew On Mon, 23 Apr 2001, Warner Losh wrote: > In message <[EMAIL PROTECTED]> Lists Account >writes: > : I just was wondering if anyone out there knew of any drivers that support > : the pccard PCI -> PCMCIA bridge adapter, also made by pccard (see > : www.pccard.co.uk), similar to the ISA -> PCMICIA bridge adapter that is > : currently supported under FreeBSD > > The simple PLX based bridges are supported for an and wi. More > complete support for them may be forthcomign. The cardbus bridge chip > on a pci card isn't (yet) supported by FreeBSD. I do have a contract > to make them work, however. > > Warner > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-hackers" in the body of the message > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
No route to host problems on 5.0-CURRENT
Hi All, Just hoping someone can help me out with a bit of a problem, I cvsupped one of my boxes from 4.3-RELEASE to 5.0-CURRENT last night in an effort to test some things under 5.0, and since then even with a straight GENERIC kernel build my machine gives me a no route to host error trying to access anything including my gateway, which is definatly up and functioning. And arp -a call shows that my gateway arp address is "incomplete", now Im wondering if there is something left out of my kernel build or if there is some other problem I can possibly resolve. Any help would be MUCH appreciated Many Thanks Andrew To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
ISA_PNP_PROBE
Hi All Just wondered, is there an equivelant function to ISA_PNP_PROBE that works with PCI (for example PCI_PNP_PROBE), anyone know? Thanks Andrew To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
More PCI->PCMCIA bridge stuff
Hi All Ok, the newcard stuff under version 5 picks up my bridge fine, and it finds my wi0 (orinoco gold card) perfectly, this is all great and I was rather ecstatic as I watched it boot and tell me all this... However the problem comes in the fact that it tries to probe pccard1 after finishing with pccard0, and the moment it does this (there is only one bridge, and only space for one card), it hangs the machine solid, not even a numlock, says something about printing cis tuplets and *boom* nothing left. Any suggestions? Andrew To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
IBM ServerRaid
Hi All, does anyone know if there are any IBM Server raid drivers for FreeBSD out there? If So can anyone tell me where I can get one Thanks Andrew To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Kernel compile problem?
Hi all, Just wondered if anyone could help me out here, Im trying to cvsup from 4.0-RELEASE to 4.1-STABLE and on a make depend on my kernel I get the following: ===> agp make: don't know how to make agp_if.c. Stop *** Error code 2 Stop in /usr/src/sys/modules. *** Error code 1 Anyone else getting this error on a build? I last cvsupped at 8:50am GMT+2 Thanks Andrew To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Packet Header Filtering
Look at IPF/IPFW they both have state table stuff in them, and analyzing the ip header is done by both as well. I would suggest you hack ipf to do what you want if it doesnt do it already. Cheers Andrew On Fri, 8 Dec 2000, Alwyn Goodloe wrote: >We are about to begin a little project that has the following requiremnet. > >Perform IP packet filtering in the following way : > > > i) look at an ip packet header. If some conditions are met let the packet pass >otherwise reject the packet. > > > ii) Look at ip packet headers of established connections and when certain > conditions are met tear down the connection. > > > Obviously this isn't the kind of thing we will be using the usual > firewall software, at least not as I understand the software. What I > want to know from you FreeBSD hackers is: > > i) if anyone has done something similar do you have any advice. > ii) Anyone know where I should start hacking. Would it be best to try to > hack the firewall code or the ipforwarding code > > Any such advise would be helpful. > > > Alwyn Goodloe > [EMAIL PROTECTED] > > > > > To Unsubscribe: send mail to [EMAIL PROTECTED] > with "unsubscribe freebsd-hackers" in the body of the message > To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
AMI MegaRaid Controller
Hi All, Perhaps one of you can help me out here, I have an AMI Megaraid controller, which my FreeBSD 4 machine picks up fine, I can see the controller no problem, I however CANNOT see scbus0 or any form of the scsi bus which will allow me to run stand alone non-raid devices on the raid scsi controller. Any ideas at all would be MUCH appreciated Many Thanks Andrew Alston To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
NOS-TUN / Natd
Hi All, Just a quick question out of interests sake, I was setting up nos-tunnels yesterday, and I had the tunnel functioning 100% perfectly, however I could not get it to NAT the remote side of the tunnel, until I put an ipfw divert 8668 ip from any to any via any statement in my firewall config. What I first tried, and this failed was to divert all incoming packets coming into tun0 and nat them going out, however the system didnt even attempt to nat packets when I tried this (I used the follow ipfw statements to try it: ipfw add 1 divert 8668 ip from any to any via tun0 (This did nothing for the packets, didnt even touch them) ipfw add 1 divert 8668 ip from any to any in recv tun0 (Try and divert anything coming in via tun0, didnt even attempt to nat these packets either). Does anyone have any idea WHY I would have to divert ALL packets instead of just those on tun0 to get the nat to work? Any help would be appreciated Thanks Andrew To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
