a daemon C skeleton
Hello,
can anyone, please, point out a C skeleton for FreeBSD daemon.
Is the following simple example correct for FreeBSD?
if (getppid() != 1)
{
signal(SIGTTOU, SIG_IGN);
signal(SIGTTIN, SIG_IGN);
signal(SIGTSTP, SIG_IGN);
if (fork() != 0)
exit(0);
setsid();
}
getrlimit(RLIMIT_NOFILE, flim);
for (fd = 0; fd flim.rlim_max; fd++)
close(fd);
chdir(/);
.
thanks in advance,
Kirill Magdalinin
[EMAIL PROTECTED]
_
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: a daemon C skeleton
man 3 daemon
On Fri, Feb 15, 2002 at 11:52:22AM +0300, Magdalinin Kirill wrote:
Hello,
can anyone, please, point out a C skeleton for FreeBSD daemon.
Is the following simple example correct for FreeBSD?
if (getppid() != 1)
{
signal(SIGTTOU, SIG_IGN);
signal(SIGTTIN, SIG_IGN);
signal(SIGTSTP, SIG_IGN);
if (fork() != 0)
exit(0);
setsid();
}
getrlimit(RLIMIT_NOFILE, flim);
for (fd = 0; fd flim.rlim_max; fd++)
close(fd);
chdir(/);
.
thanks in advance,
Kirill Magdalinin
[EMAIL PROTECTED]
_
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
--
Mark Santcroos RIPE Network Coordination Centre
http://www.ripe.net/home/mark/ New Projects Group/TTM
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: a daemon C skeleton
On 11:52+0300, Feb 15, 2002, Magdalinin Kirill wrote: Hello, can anyone, please, point out a C skeleton for FreeBSD daemon. Take a look at src/lib/libc/gen/daemon.c, man 3 daemon HTH, -- Maxim Konovalov, MAcomnet, Internet-Intranet Dept., system engineer phone: +7 (095) 796-9079, mailto:[EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
chflags schg problem
Hello hackers! What it is mean: Dial# rm kerneloverride r-xr-xr-x root/wheel schg for kernel? yrm: kernel: Operation not permitted Dial# chflags noschg /kernelchflags: /kernel: Operation not permitted Regards, Dmitry.
Re: chflags schg problem
On 15:03+0500, Feb 15, 2002, Dmitry A. Bondareff wrote: Hello hackers! What it is mean: Dial# rm kernel override r-xr-xr-x root/wheel schg for kernel? y rm: kernel: Operation not permitted Dial# chflags noschg /kernel chflags: /kernel: Operation not permitted please show sysctl kern.securelevel. man 8 init may shed a light. Regards, Dmitry. -- Maxim Konovalov, MAcomnet, Internet-Intranet Dept., system engineer phone: +7 (095) 796-9079, mailto:[EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: chflags schg problem
On Fri, Feb 15, 2002 at 03:03:10PM +0500, Dmitry A. Bondareff wrote: Hello hackers! What it is mean: Dial# rm kernel override r-xr-xr-x root/wheel schg for kernel? y rm: kernel: Operation not permitted Dial# chflags noschg /kernel chflags: /kernel: Operation not permitted http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/kernelconfig-trouble.html -- Chris D. Faulhaber - [EMAIL PROTECTED] - [EMAIL PROTECTED] FreeBSD: The Power To Serve - http://www.FreeBSD.org msg31847/pgp0.pgp Description: PGP signature
chroot+su idea
Hi all, just like many people, I want to run my dangerous daemons as a non-root user in a chroot environment. Now, I would usually use the ``su'', or ``chroot'' tools from the FreeBSD toolset in the creation of an rc.d script, but the question that puzzles me is how to combine these two measures? 1) su first, then chroot: impossible, as chroot needs to be run by root, so whenever I su to the user I cannot chroot anymore. 2) chroot first, then su: undesired, as I would have to move a suid root copy of the su tool into the chroot; also unpractical as I'd have to duplicate a lot of files into the chroot to satisfy su. Is there a tool available that combines chroot and su? If not, a chroot capability would be an interesting feature to add to the FreeBSD ``su'' command in my opinion, e.g. % su -l ircd -r /usr/local/ircd -c 'bin/ircd' Any ideas or suggestions would be welcomed. If I have overlooked a current solution for the chroot+su chicken/egg problem, I'd love to submit a patch for su to add such a chroot parameter, but I could imagine that the committer team is more conservative than I am. :) Thanks! walter -- Walter Hop [EMAIL PROTECTED] | +31 6 24290808 | PGP keyid 0x84813998 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Reading userland environnement from the kernel
Hi hackers, Is there a way to read user-land environ(7) table from the kernel for a given process ? Cheers, -- Laurent To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: chroot+su idea
cd /usr/ports less security/chrootuid/pkg-comment A simple wrapper that combines chroot(8) and su(1) into one program gook luck, olivier On Fri, Feb 15, 2002 at 02:02:49PM +0100, Walter Hop wrote: Hi all, just like many people, I want to run my dangerous daemons as a non-root user in a chroot environment. Now, I would usually use the ``su'', or ``chroot'' tools from the FreeBSD toolset in the creation of an rc.d script, but the question that puzzles me is how to combine these two measures? 1) su first, then chroot: impossible, as chroot needs to be run by root, so whenever I su to the user I cannot chroot anymore. 2) chroot first, then su: undesired, as I would have to move a suid root copy of the su tool into the chroot; also unpractical as I'd have to duplicate a lot of files into the chroot to satisfy su. Is there a tool available that combines chroot and su? If not, a chroot capability would be an interesting feature to add to the FreeBSD ``su'' command in my opinion, e.g. % su -l ircd -r /usr/local/ircd -c 'bin/ircd' Any ideas or suggestions would be welcomed. If I have overlooked a current solution for the chroot+su chicken/egg problem, I'd love to submit a patch for su to add such a chroot parameter, but I could imagine that the committer team is more conservative than I am. :) Thanks! walter -- Walter Hop [EMAIL PROTECTED] | +31 6 24290808 | PGP keyid 0x84813998 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message -- Olivier Cortes GPG 1024/46CE0A51 : 8DB6 A56C 00CA DA0F F77F 86EB E86A 803C 46CE 0A51 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: chroot+su idea
On Fri, Feb 15, 2002 at 02:02:49PM +0100, Walter Hop wrote: 2) chroot first, then su: undesired, as I would have to move a suid root copy of the su tool into the chroot; also unpractical as I'd have to duplicate a lot of files into the chroot to satisfy su. Have you tried using a non-suid copy of su in the chroot? I'd guess it would work OK as it would be running as root anyway. David. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Reading userland environnement from the kernel
On Fri, Feb 15, 2002 at 02:15:34PM +, Sansonetti Laurent wrote: Is there a way to read user-land environ(7) table from the kernel for a given process ? Does 'ps -auxwwwe' do what you want? David. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re[2]: chroot+su idea
[in reply to [EMAIL PROTECTED], 15-02-2002] cd /usr/ports less security/chrootuid/pkg-comment A simple wrapper that combines chroot(8) and su(1) into one program Great, how could I have overlooked that one? Thanks!! :) walter -- Walter Hop [EMAIL PROTECTED] | +31 6 24290808 | PGP keyid 0x84813998 To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
RE: Reading userland environnement from the kernel
Hi, Is there a way to read user-land environ(7) table from the kernel for a given process ? You have to look at the proc structure for a process and there you will find a buffer for the 'ps_strings' and a few offset variables to show where the environment variables are. Andy Cheers, -- Laurent 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
lpd filter stderr log files
Unfortunately, some changes in the lpd code that happened last year (as far as I remember) are very disadvantageous for the operation of our (heavily loaded) printer server which is based on FreeBSD for years now. My input filter programs are designed to write useful debugging information to stderr while processing print jobs. Prior to the changes, we could observe the progress of print jobs by a `tail -f /var/log/lpd-err/queue_log_file'. Now, all information written by the filter programs to stderr gets catched by temporary log files the names of which are created randomly. After a print job has completed, the contents of the temporary file is appended to the queue log file. For our purposes, that's often too late. Why have these changes been made? And can the old behaviour be restored? We really would like to see what happens during printing a job (imagine a 300 mb postscript print job which may a lot of time to execute completely). I already looked a the source code, and probably I could change a lot by myself, but this seems to be a bad idea since the next cvs update will happen, of course. I don't know who is responsible for the lpd code in the FreeBSD developers team, so please forward this mail to him/her if he/she doesn't read freebsd-hackers. And please think about my request - the old behaviour helped us a lot. Best regards Konrad HeuerPersonal Bookmarks: Gesellschaft für wissenschaftliche Datenverarbeitung mbH GÖttingen http://www.freebsd.org Am Faßberg, D-37077 GÖttingen http://www.daemonnews.org Deutschland (Germany) [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Reading userland environnement from the kernel
Hi Terry (and others!) You seem to know a lot about the kernel (as you always expand on my Cliff Notes versions of my answers). Can you give me any hints on the device driver question I posted a few days ago. There was a response, however I don't see how it applies for these reasons. 1. When the hardware (board) is inserted, but no kernel driver there are no failures. 2. When the hardware is installed with the minimal kernel driver the system locks. The minimal kernel driver only attaches some resources. 3. When doing the full initialization of the device (which works in NetBSD) there are also the SAME failures as doing no initialization at all of the hardware (as seen in the samples posted). 4. The device driver does not use MBUFS at all. Any ideas!?? :-) Thanks much in advance! Andy On 15-Feb-02 Terry Lambert wrote: Sansonetti Laurent wrote: Hi hackers, Is there a way to read user-land environ(7) table from the kernel for a given process ? Yes and no, or we'd already have implemented variant symbolic links. The problem is manifold: 1)The environment is pointed to by the environ ** pointer in the user process. The location of the environ ** pointer is not well known. 2)The environ ** value may be overridden by the user program entirely, so the pages where the data lives aren't where the are expected, so a saved pointer to envp *[] at execve time is not a workaround 3)The envrion ** is require by POSUCKS (sometimes spelled POSIX), so getting rid of it and making the getenv/setenv/putenv/unsetenv functions use a multiplex system call is not an option that maintains POSIX compliance. 4)It's hard to satisfy #2 and #3 and maintain binary compatability; the gross way you could do this is to save two copies of environ **, the real one at startup, and the shadow one called environ **, and then if the shadow does not match the real, fall back to the historical behaviour. Synchornizing means that you would need to know when the change happens (not possible, unless you catch a write fault and implicitly fix it up, like SVR4 does with page zero pointer dereferences, unless you specifically tune the kernel to fault fatally on them), or you would have to reflect all kernel level changes into the user space area shadow (expensive, but doable). 5)The execve() envp *[] passing is tricky, at best, for a modified implementation, since you have to read it back to pass it down. One option, which fails POSIX again, is to pass the default in if there is a NULL passed here, for an in kernel implementation (actually, you don't have to pass anything for the user environment, if the system and group contain everything you care about). 6)You can also put the environ ** into user pages (read only) that are also mapped into a pointer off the proc structure (read/write), so that the kernel changes are visible to user space. This makes it so that environ ** is not writable, but it is OK to read it, so a minimum number of changes are required for system/group/user logical names. I run with a variant of #6 on one of my machines; I use the same page I use for the environ ** for the pid, gid, and other data to make them zero kernel overhead for getpid, getppid, getgid, etc. -- basically, any system call that only reads a small fixed sized data value. This still means that the environment is stored in the user space process, but the current environ ** is always known to the kernel, and if it needs to be modified, it takes a system call. It's pretty cool: it lets me set the environment variables for processes from other processes, and everyone inherits from init's environment (system logical name table), the process group leader's (if they aren't the leader themselves: group logical name table) and then themselves, in increasing priority, on getenv(). But of course, it violates the writability of **environ, which POSUCKS wants, but I don't care (on that machine, signals default to restarting system calls so that my user space threads library is incredibly light weight, and getting the one-close-destroys-all-locks-even-for-other-opens behaviour is non-default, too... you have to fcntl(F_POSIX)). -- Terry 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
Re: chroot+su idea
Also have a look at jail(8). -- Crist J. Clark | [EMAIL PROTECTED] | [EMAIL PROTECTED] http://people.freebsd.org/~cjc/| [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: lpd filter stderr log files
At 3:16 PM +0100 2/15/02, Konrad Heuer wrote: Unfortunately, some changes in the lpd code that happened last year (as far as I remember) are very disadvantageous for the operation of our (heavily loaded) printer server which is based on FreeBSD for years now. Well, I'm willing to see what we can do to help you out. Prior to the changes, we could observe the progress of print jobs by a `tail -f /var/log/lpd-err/queue_log_file'. Now, all information written by the filter programs to stderr gets catched by temporary log files the names of which are created randomly. After a print job has completed, the contents of the temporary file is appended to the queue log file. Hmm. I suspect that any change there is more than a year old. We did change how the temporary-files were generated, but I think lpd has used temporary files for stderr for a long time. For our purposes, that's often too late. Why have these changes been made? And can the old behaviour be restored? I think the reason it's done this way (with the temporary files) is so multiple queues could point to a single log file, and so all the lines for any one job would be added onto that log file in one shot. I think there's a number of other reasons too. A quick look at the history for lpd/printjob.c seems to indicate that it has always behaved this way (or at least, it was always the *intention* that it behave this way, perhaps there were some bugs fixed). We really would like to see what happens during printing a job (imagine a 300 mb postscript print job which may a lot of time to execute completely). Well, here we see 1-gig postscript files going to our plotters, so it's pretty easy for me to imagine a 300-meg one... :-) It's obvious that you just changed to a new version of lpr. Did you also change any of your scripts? In some of my scripts, what I do is: exec 2$LPD_LOG_dir/$pname/log This causes the *script* to redirect stderr to where I want it. Would that work in your situation? -- Garance Alistair Drosehn= [EMAIL PROTECTED] Senior Systems Programmer or [EMAIL PROTECTED] Rensselaer Polytechnic Instituteor [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Odd ipfw behaviour
ipfw seems to be confused about where to forward packets if no interface is specifically mentioned. Before I file a PR on it, I'd like someone who is more familiar with how ipfw operates to quickly look over my findings. Test setup, showing 2 ethernets with 2 FreeBSD boxes and another machine running netscape +---NetscapeBROWSERbox +---squid SQUIDbox +---4.5 Release--+ ProxyFirewall router---+ | internet The internal net on ProxyFirewall is fxp1, external net is fxp0. All devices have real IP addresses and correct netmasks NAT is not involved. Using this ipfw rule on ProxyFirewall: fwd $(squid-box) log tcp from $(windows-box) to any 80 and checking the logs on ProxyFirewall, I see this horrible mess: ipfw: 11005 Forward to SQUIDbox TCP BROWSERbox:1631 216.136.204.21:80 in via fxp1 ipfw: 11005 Forward to SQUIDbox TCP BROWSERbox:1631 216.136.204.21:80 out via fxp0 ---!!! ipfw: 11005 Forward to SQUIDbox TCP BROWSERbox:1631 216.136.204.21:80 in via fxp1 ipfw: 11005 Forward to SQUIDbox TCP BROWSERbox:1631 216.136.204.21:80 out via fxp1 ipfw: 6 Deny ICMP:5.1 ProxyFirewall BROWSERbox out via fxp1 ipfw: 6 Deny ICMP:5.1 ProxyFirewall SQUIDbox out via fxp1 last message repeated 31 times This, of course, causes terrible performance as the packets destined for the local net bounce out the default interface. It can be corrected by specifying an interface in the fwd rule: fwd $(squid-box) log tcp from $(windows-box) to any 80 via fxp1 Is it expected behaviour for ipfw to disregard routing and put packets out on interfaces where they have no chance of being properly delivered (which would be odd) or is this a bug? /\/\ \/\/ To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
RE: IPv6-over-IPv4 problems since the upgrade to 4.5
I cannt reproduce it. Whats the version of the NetBSD box on other side? Does somebody IPv6 routing in your segment? Igor. -Original Message- From: Edwin Groothuis [mailto:[EMAIL PROTECTED]] Sent: Monday, February 11, 2002 8:30 PM To: [EMAIL PROTECTED] Subject: IPv6-over-IPv4 problems since the upgrade to 4.5 Greetings, Since the upgrade from 4.4 to 4.5 I have problems with my ipv6-over-v4-tunnel towards the freenet6-servers. The tunnel-setup goes fine, I can ping everything without a problem. But when I open an interactive session, after a short time weird things happen: The tcp-session itself goes fine, until the moment my machine starts sending out icmp6 neighbor solicitation requests: tcp-session setup: 19:46:39.452386 mavetju-k7.tsps1.freenet6.net.1761 ftp6.netbsd.org.ftp: S 1971097502:1971097502(0) win 65535 mss 1220,nop,wscale 1,nop,nop,timestamp 12158080 0 19:46:40.00 ftp6.netbsd.org.ftp mavetju-k7.tsps1.freenet6.net.1761: S 4240147676:4240147676(0) ack 1971097503 win 32768 mss 1440,nop,wscale 0,nop,nop,timestamp 12009124 12158080 19:46:40.077880 mavetju-k7.tsps1.freenet6.net.1761 ftp6.netbsd.org.ftp: . ack 1 win 33220 nop,nop,timestamp 12158143 12009124 220 ftp6.netbsd.org FTP server (NetBSD-ftpd 20020201) ready. 19:46:40.767713 ftp6.netbsd.org.ftp mavetju-k7.tsps1.freenet6.net.1761: P 1:63(62) ack 1 win 33120 nop,nop,timestamp 12009126 0 [flowlabel 0x80114] 19:46:40.867511 mavetju-k7.tsps1.freenet6.net.1761 ftp6.netbsd.org.ftp: . ack 63 win 33220 nop,nop,timestamp 12158222 12009126 the weird neighbor solicitation packets: 19:46:44.697259 mavetju-k7.tsps1.freenet6.net ftp6.netbsd.org: icmp6: neighbor sol: who has ftp6.netbsd.org 19:46:45.697183 mavetju-k7.tsps1.freenet6.net ftp6.netbsd.org: icmp6: neighbor sol: who has ftp6.netbsd.org 19:46:46.697131 mavetju-k7.tsps1.freenet6.net ftp6.netbsd.org: icmp6: neighbor sol: who has ftp6.netbsd.org user anonymous 19:46:47.201295 mavetju-k7.tsps1.freenet6.net.1761 ftp6.netbsd.org.ftp: P 1:17(16) ack 63 win 33220 nop,nop,timestamp 12158855 12009126 331 Guest login ok, type your name as password. 19:46:47.897276 ftp6.netbsd.org.ftp mavetju-k7.tsps1.freenet6.net.1761: P 63:112(49) ack 17 win 33120 nop,nop,timestamp 12009140 12158855 [flowlabel 0x80114] 19:46:50.147087 ftp6.netbsd.org.ftp mavetju-k7.tsps1.freenet6.net.1761: P 63:112(49) ack 17 win 33120 nop,nop,timestamp 12009144 12158855 [flowlabel 0x80114] 19:46:55.196847 ftp6.netbsd.org.ftp mavetju-k7.tsps1.freenet6.net.1761: P 63:112(49) ack 17 win 33120 nop,nop,timestamp 12009154 12158855 [flowlabel 0x80114] 19:47:05.256189 ftp6.netbsd.org.ftp mavetju-k7.tsps1.freenet6.net.1761: P 63:112(49) ack 17 win 33120 nop,nop,timestamp 12009174 12158855 [flowlabel 0x80114] 19:47:25.234907 ftp6.netbsd.org.ftp mavetju-k7.tsps1.freenet6.net.1761: P 63:112(49) ack 17 win 33120 nop,nop,timestamp 12009214 12158855 [flowlabel 0x80114] 19:48:05.212334 ftp6.netbsd.org.ftp mavetju-k7.tsps1.freenet6.net.1761: P 63:112(49) ack 17 win 33120 nop,nop,timestamp 12009294 12158855 [flowlabel 0x80114] These tcp-packet never gets acknowledged and my packets never get send! After having done several tests, with ftp, ssh and plain telnet, everything goes fine until just after the neighbor solicitation. But icmp-traffic, even large packets as 4Kb, go without a problem. FreeBSD 4.4 doesn't have this behaviour. Can somebody please confirm that they have the same, or normal, behaviour under 4.5 when connecting to an IPv6 enabled site. Thanks, Edwin -- Edwin Groothuis | Personal website: http://www.MavEtJu.org [EMAIL PROTECTED] | Interested in MUDs? Visit Fatal Dimensions: --+ http://www.FatalDimensions.org/ 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
Re: a daemon C skeleton
try
daemon(args..);
.
(man 3 daemon)
On Fri, 15 Feb 2002, Magdalinin Kirill wrote:
Hello,
can anyone, please, point out a C skeleton for FreeBSD daemon.
Is the following simple example correct for FreeBSD?
if (getppid() != 1)
{
signal(SIGTTOU, SIG_IGN);
signal(SIGTTIN, SIG_IGN);
signal(SIGTSTP, SIG_IGN);
if (fork() != 0)
exit(0);
setsid();
}
getrlimit(RLIMIT_NOFILE, flim);
for (fd = 0; fd flim.rlim_max; fd++)
close(fd);
chdir(/);
.
thanks in advance,
Kirill Magdalinin
[EMAIL PROTECTED]
_
Get your FREE download of MSN Explorer at http://explorer.msn.com/intl.asp.
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
Re: chroot+su idea
check out 'jail' start the daemon within the startup script of the jail. On Fri, 15 Feb 2002, Walter Hop wrote: Hi all, just like many people, I want to run my dangerous daemons as a non-root user in a chroot environment. Now, I would usually use the ``su'', or ``chroot'' tools from the FreeBSD toolset in the creation of an rc.d script, but the question that puzzles me is how to combine these two measures? 1) su first, then chroot: impossible, as chroot needs to be run by root, so whenever I su to the user I cannot chroot anymore. 2) chroot first, then su: undesired, as I would have to move a suid root copy of the su tool into the chroot; also unpractical as I'd have to duplicate a lot of files into the chroot to satisfy su. Is there a tool available that combines chroot and su? If not, a chroot capability would be an interesting feature to add to the FreeBSD ``su'' command in my opinion, e.g. % su -l ircd -r /usr/local/ircd -c 'bin/ircd' Any ideas or suggestions would be welcomed. If I have overlooked a current solution for the chroot+su chicken/egg problem, I'd love to submit a patch for su to add such a chroot parameter, but I could imagine that the committer team is more conservative than I am. :) Thanks! walter -- Walter Hop [EMAIL PROTECTED] | +31 6 24290808 | PGP keyid 0x84813998 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
bktr driver signaling broken
Okay after bashing my skull against this problem for some time now, I've narrowed this problem down. What Im attempting to do is get a signal from the bktr driver after each frame is posted. The code in the kernel supports this. It even works for some output formats. The problem is the driver never sees a completed frame in continous mode, unless your in RGB16 (possibly others, I havent checked). If your in YUV mode, you get signaling something like so: Field is 1 [EVEN:2, ODD:1] Completed field 00311243 00311243 Complete frame? 00111243 30 = 10 Field is 1 [EVEN:2, ODD:1] Completed field 00111243 00111243 Out of sync, starting over Field is 2 [EVEN:2, ODD:1] Completed field 00311243 00311243 Out of sync, starting over Field is 1 [EVEN:2, ODD:1] Completed field 00311243 00311243 Complete frame? 00111243 30 = 10 Field is 1 [EVEN:2, ODD:1] Completed field 00111243 00111243 Out of sync, starting over Field is 2 [EVEN:2, ODD:1] Completed field 00311243 00311243 Where for some reason the (card/driver?) is signalling incorrect field ordering (or correct, I dont have the docs). In any case the driver feels since it doesnt have a nice 2 field frame, it never enters the signal the app there is a frame code. Any of the authors of this driver, or anyone with brooktree experience got any ideas? -Crh Charles Henrich Eon Entertainment [EMAIL PROTECTED] http://www.sigbus.com:81/~henrich To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
