Re: Is there any way to know if userland is patched?
On Thu, Nov 11, 2004 at 02:30:46AM +0800, Xin LI wrote: I have an idea that is somewhat too complex to be included in FreeBSD - we maintain a ``master'' patchlevel, and two patchlevels indicating the least ``master'' patchlevel that touches kernel or userland. It might be something like this: Master| Userland | Kernel +===+=== 4.10-RELEASE | 4.10-RELEASE | 4.10-RELEASE 4.10-RELEASE-p1 | 4.10-RELEASE | 4.10-RELEASE-p1 4.10-RELEASE-p2 | 4.10-RELEASE | 4.10-RELEASE-p2 4.10-RELEASE-p3 | 4.10-RELEASE-p3 | 4.10-RELEASE-p2 And propograte it somewhere. This is somewhat complex as the security officer must bump two version when he is doing a security update and I'm not sure whether this is beneficial enough so I hesitate to proposal a patch of this, Actually, some time ago I thought of doing something quite similar. At first, I wanted to alter uname(3) to return not the kernel version, but a userland version string. Borrowing from the way Solaris does it, I thought we'd just stick the version in /etc/release. That way patching /etc/release would be sufficient for userland issues. But of course that doesn't help us with kernel issues, and the fact that kernel and userland can accidently get out of sync. So I thought perhaps we'd have a patch level for userland, and a patch level for the kernel. Some patches would touch only the userland patch level, and some the kernel patch level. There would also be recorded in userland what the latest kernel patch level should be. Then uname(3) would display the patch level according to whether the latest kernel is loaded. (I know, this is a hard to follow description.) Something like so: userland_pl Patch level of currently installed userland. expected_kernel_pl Patch level of currently installed kernel. kernel_plPatch level of currently running kernel. Then, uname(3) will choose what patch level to display like so: if (kernel_pl expected_kernel_pl || kernel_pl userland_pl) return kernel_pl; else return userland_pl; (Actually, we would probably make patch level bumps such that the kernel_pl userland_pl case never happens.) In the end, what we want is for a user to type `uname -r' and to see what patch level is running. Anything more complicated (checking RCS Ids and such) just gets in the way, I think. Cheers, -- Jacques A Vidrine / NTT/Verio [EMAIL PROTECTED] / [EMAIL PROTECTED] / [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: nsdispatch services patch + lookupd
On Wed, Oct 27, 2004 at 09:33:33AM +0200, Danny Braniss wrote: while trying to add hesiod/dns support, i've noticed, what looks as a problem: in nss_tls.h, the function name##_getstate(...) can return a static pointer, which gets freed in name##_endstate(...), as far as i know, freeing a non malloced memory is asking for trouble. proposed fix, instead of static, also do a calloc(...). Yes, looks like you are correct. I will fix this month. Thanks for the report! (Is there already a PR?) Cheers, -- Jacques A Vidrine / NTT/Verio [EMAIL PROTECTED] / [EMAIL PROTECTED] / [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: nsdispatch services patch + lookupd
On Tue, Oct 26, 2004 at 02:17:49PM +0400, Michael Bushkov wrote: Hello! I've been asking to commit nsdispatch services patch (the patch, which makes getserv* functions run over nsdispatch interface) since the middle of summer. And it's still not committed. The problem is that the next release of the lookupd daemon (which i support) depends on this patch, as it implements 'services' data source. I've included the patch once again here. Is it possible to commit it in the nearest future? I'll handle this month. Could you open a PR? Cheers, -- Jacques A Vidrine / NTT/Verio [EMAIL PROTECTED] / [EMAIL PROTECTED] / [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Protection from the dreaded rm -fr /
On Sat, Oct 02, 2004 at 10:43:49PM +1000, Peter Jeremy wrote: I've had a customer write a cronjob that did almost exactly this. He managed to 'test' it on all the (redundant) production systems as well as the test model. We were only called in when he found that there were some unexpected console messages and the systems wouldn't boot when he pressed the reset button. Luckily it managed to kill itself before it destroyed all the evidence (since the culprit initially denied doing anything). Based on that, I'm definitely in favour of some anti-foot-shooting measures. [...] FWIW, I'm not in favor of adding ad-hoc features to handle edge-cases. (feature because this is actually introducing a bug :-) I picked this email to which to respond, because I can share my own stupidity. Case much like the one described above, but my cronjob included something like: cd /path/to/directory/with/temporary/files rm -fr * Only another admin removed `/path/to/directory/with/temporary/files'... so the `cd' failed and left the current directory as `/'. For some reason the system crashed :-) ... and then crashed again a few days after restoring from backup... doh! Will the next step be to prevent `rm -fr *' iff the current working directory is '/' ? Please explain your answer. :-) Cheers, -- Jacques A Vidrine / NTT/Verio [EMAIL PROTECTED] / [EMAIL PROTECTED] / [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: Older releases? was Re: FreeBSD Security Advisory FreeBSD-SA-02:21.tcpip
On Fri, Apr 19, 2002 at 09:59:14AM -0500, D J Hawkey Jr wrote: Developers: Userland is affected here - /usr/lib/libz. Would a make make install (sic) in /usr/src/lib/libz before building the kernel suffice for a solid upgrade? No, the src/lib/libz is --- as you note --- for userland. It is not used by the kernel. Note that the patch includes updates to the kernel source as well. Also note that `savecore' statically links libz, so it must be recompiled and reinstalled also. I don't believe there are any other programs in the base system that statically link libz. Cheers, -- Jacques A. Vidrine [EMAIL PROTECTED] http://www.nectar.cc/ NTT/Verio SME . FreeBSD UNIX . Heimdal Kerberos [EMAIL PROTECTED] . [EMAIL PROTECTED] . [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-security in the body of the message ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: kernel modules programming: struct proc question
On Wed, Mar 17, 2004 at 04:45:30PM +0100, Toni Andjelkovic wrote: On Wed, Mar 17 2004 (17:00:02 +0200), Artis Caune wrote: pid_t is signed int type, or am I missing something? You are right, pid_t is __int32_t, which is signed, so %d is the correct format. That's only correct for machines with 32-bit ints. In any case, POSIX only specifies that pid_t is a signed integer type... it could be any size supported by the implementation. For portability, you probably want to cast to the `biggest' type and use the appropriate printf specifier, e.g. printf(%ld, (long)pid_t); or printf(%jd, (intmax_t)pid_t); // C99 Cheers, -- Jacques Vidrine / [EMAIL PROTECTED] / [EMAIL PROTECTED] / [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: kernel modules programming: struct proc question
On Wed, Mar 17, 2004 at 09:36:39PM +0300, Roman Bogorodskiy wrote: static int new_open(struct proc *p, register struct open_args *uap) Er, the first argument passed to a system call in 5.x is a `struct thread', not a `struct proc'. Cheers, -- Jacques Vidrine / [EMAIL PROTECTED] / [EMAIL PROTECTED] / [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: IPC nsswitch implementation
[We need to pick a list and stop cross-posting. I pick [EMAIL PROTECTED]'.] On Fri, Mar 05, 2004 at 10:41:33PM +0300, Michael Bushkov wrote: The problem of using Darwin's lookupd was discussed some time ago in the freebsd-arch mailing list. It seems to me that the way to port Darwin's lookupd on FreeBSD was not found, was it? Jordan's message was the first I recall mentioning lookupd. I took a quick peek, seems neat. I'd like to take some more time to examine the APIs it presents. I also intend to look at what you have. Our implementation of lookupd is a demonstration of the approach for the FreeBSD-specific IPC implementation of nsswitch. Its architecture is flexible enough to implement all the features you have mentioned. The version that we have sent isn't a finished project. It's in the development stage and caching is currently our main task. We hope to make caching in the nearest future. We'll try to release stable and quite full version (i mean caching, LDAP module and so on) as soon as we can. You're not going to have to write your own modules (like LDAP), are you? That seems like a big drawback. Our questions are: 1) What do you think about our whole approach to the IPC implementation development? 2) Is there an opportunity to use our implementation of lookupd in the FreeBSD project? We'll be glad to hear your opinion. I'll certainly look at what you have and send comments to this list, but I'm afraid it won't be immediate. You may also want to ping NetBSD guys. Cheers, -- Jacques Vidrine / [EMAIL PROTECTED] / [EMAIL PROTECTED] / [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: mostly-reentrant resolver/getaddrinfo(3)
[ Brian: I've noticed that in the recent past, I cannot receive email from you due to reject: RCPT from mx2.freebsd.org[216.136.204.119]: 450 [EMAIL PROTECTED]: Sender address rejected: Domain not found Requests for any green.bikeshed.org RRs results in SERVFAIL. ] On Sat, Feb 07, 2004 at 07:01:47PM -0500, Brian F. Feldman wrote: BTW, a slightly more complete patch that has the diffs for /usr/include/resolv.h and also should correctly close the sockets that each thread opens for the resolver can be found here: http://green.homeunix.org/~green/mostly_reentrant_resolver.patch Cool! Use pthread_once for creating keys, not a mutex (referring to res_init_mutex/res_keys_inited). I prefer to see `_pthread_*' in libc source (rather than `thr_*'), but that's just me. Cheers, -- Jacques Vidrine NTT/Verio SME FreeBSD UNIX Heimdal [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: binary files in src tree
On Sun, Jan 11, 2004 at 05:48:19PM +, Colin Percival wrote: While browsing the FreeBSD src tree, I came across a number of binary files (listed below); the regression tests are perhaps understandable, but shouldn't the rest of these files be uuencoded? contrib/groff/doc/gnu.png contrib/ipfilter/samples/ipfilter-pb.gif contrib/sendmail/libmilter/docs/figure1.jpg contrib/sendmail/libmilter/docs/figure2.jpg crypto/openssh/regress/copy.1 crypto/openssh/regress/copy.2 crypto/openssh/scard/Ssh.bin crypto/openssl/crypto/pkcs7/p7/a1 crypto/openssl/crypto/pkcs7/p7/a2 crypto/openssl/crypto/pkcs7/p7/cert.p7c crypto/openssl/crypto/pkcs7/p7/smime.p7m crypto/openssl/crypto/pkcs7/p7/smime.p7s crypto/openssl/doc/openssl_button.gif release/picobsd/tinyware/view/fbsd.png tools/regression/usr.bin/file2c/regress.in tools/regression/usr.bin/uudecode/regress.out tools/regression/usr.bin/uuencode/regress.in tools/tools/tinderbox/www/daemon.png tools/tools/tinderbox/www/valid-css.png tools/tools/tinderbox/www/valid-xhtml10.png Colin Percival Those that are found in src/contrib/ and src/crypto/, at least, should not be touched. However, it seems likely that some or all of them in that case are not actually used in FreeBSD. Those that are not used should perhaps be removed. I'll put reviewing the src/crypto/openssl/ cases on my todo list for the next import. Cheers, -- Jacques Vidrine NTT/Verio SME FreeBSD UNIX Heimdal [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: nsswitch/libnss_winbind.so problem
On Thu, Dec 18, 2003 at 03:31:50AM -0700, [EMAIL PROTECTED] wrote: Hello all! I'm running FreeBSD v. 5.1 I'm having problems getting commands like chmod and chown to read winbind data. I've installed samba from ports with the make WITH_WINBIND_NSS=yes compile option. Did you also make WITH_WINBIND_NSS=yes install or just `make install' ? Port make options must be set for every stage (configure, build, install, package, etc). I've also created a /etc/nsswitch.conf file containing: passwd: files winbind group: files winbind I've copied the : /usr/ports/net/samba/work/samba-2.2.8a/source/nsswitch/libnss_winbind.so to: /usr/lib (also tried /usr/local/lib) This is not necessary. If the port was correctly installed, you will have /usr/local/lib/nss_winbind.so.1. What is the output of pkg_info -L samba-\* | grep nss_winbind ? I've done all the nessecary samba configurations, and can get user and groups with : wbinfo -u and -g. I've allso joined my NT domain with no problems, so winbind is working properly. The thing is that commands like chmod and chown can not assign to the winbind gathered user/group list. I belive these commands use the information from /etc/nsswitch.conf when they get usernames and groupnames? I just get invalid argument when trying to chown a file to a user from the winbind list. Please help me out! Do you see anything in syslog at LOG_DEBUG level? Cheers, -- Jacques Vidrine NTT/Verio SME FreeBSD UNIX Heimdal [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: patchlevels and FreeBSD source
On Tue, Nov 25, 2003 at 08:09:56PM -0500, [EMAIL PROTECTED] wrote: My question is: Is it possible that I update my cdrom image to the to 4.8-RELEASE-p15 before install ? In other words, are the patches that released as source diffs also available as downloadable cd images? Currently, no, but I hope this to change in the near future. -- Jacques Vidrine NTT/Verio SME FreeBSD UNIX Heimdal [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: can't find kernel source tree error when building the kernel.
On Fri, Oct 03, 2003 at 07:57:51PM +0300, Clau wrote:
hello,
i just downloaded via cvsup the latest kernel for freebsd 5.1.
i had a problem with it, more exactly when i did a make depend
it stopped at some place, and gave me this error:
can't find kernel source tree
i fixed this by modifying this piece of code from /usr/src/sys/conf/kmod.mk
(it starts with line 167 in the file)
.for _dir in ${.CURDIR}/../.. ${.CURDIR}/../../.. /sys /usr/src/sys
.if !defined(SYSDIR) exists(${_dir}/kern/)
SYSDIR= ${_dir}
.endif
.endfor
.if !defined(SYSDIR) || !exists(${SYSDIR}/kern/)
.error can't find kernel source tree
.endif
i removed the last / from /kern/ and now it seems it can find the
directory.
i don't know if this is a general problem, or it is just in the case of
my system.
How are you building the kernel? Are you using `make buildworld' first
and then `make buildkernel' (or `make kernel')?
Cheers,
--
Jacques Vidrine . NTT/Verio SME . FreeBSD UNIX . Heimdal
[EMAIL PROTECTED] . [EMAIL PROTECTED] . [EMAIL PROTECTED] . [EMAIL PROTECTED]
___
[EMAIL PROTECTED] mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-hackers
To unsubscribe, send any mail to [EMAIL PROTECTED]
Re: pam_ldap...
On Wed, Mar 26, 2003 at 10:25:48AM -0800, Tak Pui LOU wrote: Does that mean there will be official support for nss_ldap in FBSD 5.1? It is expected that a FreeBSD Port of nss_ldap will be available by FreeBSD 5.1. Is it on the -current right now? I would like to test it. It is not in -CURRENT yet. Cheers, -- Jacques A. Vidrine [EMAIL PROTECTED] http://www.celabo.org/ NTT/Verio SME . FreeBSD UNIX . Heimdal Kerberos [EMAIL PROTECTED] . [EMAIL PROTECTED] . [EMAIL PROTECTED] ___ [EMAIL PROTECTED] mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-hackers To unsubscribe, send any mail to [EMAIL PROTECTED]
pthread keys and resource leaks
Hi All, Please show me how stupid I am :-) There does not appear to be a way to avoid resource leaks in a library that must manage thread-local storage. The problem appears to be that the destructor given to pthread_key_create is not called for the `main thread' (uncertain terminology). Example: library private freekey() free resources, like fds deallocate thread-local storage public foo() pthread_once - initialize pthread_key pthread_getspecific - fetch thread-local storage if there wasn't any already allocated, allocate thread-local storage maybe initialize some stuff, like fds do your thing pthread_setspecific - update thread-local storage main 1. call foo() 2. create thread that calls foo() 3. pthread_join() Both invocations of foo() will work correctly: they will each have their own thread-local storage allocated. When the thread created at (2) exits, freekey() will be called. But, when the process exits, freekey() will NOT have been called for the invocation of foo at (1) (what I am calling the `main thread'). I'm pretty certain I'm using pthread_(set|get)specific in the spirit intended. Am I misunderstanding something, or is this a flaw in our implementation? (BTW, this holds for -CURRENT and -STABLE.) Cheers, -- Jacques A. Vidrine [EMAIL PROTECTED] http://www.celabo.org/ NTT/Verio SME . FreeBSD UNIX . Heimdal Kerberos [EMAIL PROTECTED] . [EMAIL PROTECTED] . [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: ssh/ssl linkage
On Wed, Mar 05, 2003 at 01:55:14PM -0800, Julian Elischer wrote: OpenSSH uses openssl to a great extent, however when you do [ ... ] so my question is: how is the connection made to libssl? is it via libcrypto? is it statically built into the ssh binary? OpenSSH doesn't actually use SSL/TLS (libssl). It only uses the general cryptography library of OpenSSL (libcrypto). If I upgrade openssl due to teh security upgrade, should I recompile ssh as well? Yes, you must. (See below.) On Wed, Mar 05, 2003 at 02:10:45PM -0800, Julian Elischer wrote: to answer myself a bit.. It looks like openssl generates two parts: libcrypto and libssl Right. If I upgrade openssl, I should make a new libcrypto and libssl and since ssh uses only libcrypto, I should not need to upgrade ssh.. I assume you mean `rebuild' rather than `upgrade'. If I'm wrong.. let me know :-) You are wrong, but it's not your fault :-) OpenSSH specifically checks the version of OpenSSL which it finds at runtime, and if it does not match the version it found at build-time, then it barfs with OpenSSL version mismatch. Built against FOO, you have BAR The OpenSSH guys don't trust that the semantics of the API stay the same across releases, even if the ABI stays the same. I guess I cannot blame them for this extra paranoia. Cheers, -- Jacques A. Vidrine [EMAIL PROTECTED] http://www.celabo.org/ NTT/Verio SME . FreeBSD UNIX . Heimdal Kerberos [EMAIL PROTECTED] . [EMAIL PROTECTED] . [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: finding changes from one release/patch level to another?
On Fri, Feb 07, 2003 at 09:26:49AM -0500, Daniel Ellard wrote: Something slightly broke the em (gigabit ethernet) driver between 4.6.2p4 and 4.6.2p6, and I'm trying to figure what the change was so I can back it out on my machine. In 4.6.2p6 almost everything works, but programs that push the device (such as netperf) can hang. The same program running on other ethernet devices (fxp, xl) works fine. This happens on several machines, and they were all running correctly before I updated them, so I doubt that it is a hardware problem. I don't see any changes for the em driver source itself between p4 and p6, and the announced differences between these patch levels don't look related, but something must have changed. It seems awfully unlikely that the changes between 4.6.2p4 and 4.6.2p6 have anything to do with your problem. I think you are probably barking up the wrong tree. Is there a straightforward way to track down all the source code differences between p4 and p6 (or any arbitrary pair of patchlevels)? Check out the RELENG_4_6 branch. Then run e.g. cvs -q diff -j 'RELENG_4_6:2002/10/28' -j 'RELENG_4_6:2003/01/08' Output attached to save you the trouble. Cheers, -- Jacques A. Vidrine [EMAIL PROTECTED] http://www.celabo.org/ NTT/Verio SME . FreeBSD UNIX . Heimdal Kerberos [EMAIL PROTECTED] . [EMAIL PROTECTED] . [EMAIL PROTECTED] Index: UPDATING === RCS file: /home/ncvs/src/UPDATING,v retrieving revision 1.73.2.68.2.30 retrieving revision 1.73.2.68.2.32 diff -c -r1.73.2.68.2.30 -r1.73.2.68.2.32 *** UPDATING26 Oct 2002 21:11:30 - 1.73.2.68.2.30 --- UPDATING6 Jan 2003 12:38:21 - 1.73.2.68.2.32 *** *** 17,29 updates that don't have an advisory, or to be safe, you can do a full build and install as described in the COMMON ITEMS section. ! 20021026: p4 smrsh bypass bug. ! 20021023: p3 Correct kadmind buffer overflow. ! 20020911: p2 The kvm_openfiles/kvm_open functions now mark the returned file descriptors close-on-exec in case set-user-ID/set-group-ID applications are careless. --- 17,35 updates that don't have an advisory, or to be safe, you can do a full build and install as described in the COMMON ITEMS section. ! 20030106: p6 FreeBSD-SA-02:44.filedesc ! Correct a reference counting bug in fpathconf(2). ! ! 20021113: p5 FreeBSD-SA-02:43.bind ! Correct name server vulnerabilities. ! ! 20021026: p4 FreeBSD-SA-02:41.smrsh smrsh bypass bug. ! 20021023: p3 FreeBSD-SA-02:40.kadmind Correct kadmind buffer overflow. ! 20020911: p2 FreeBSD-SA-02:39.libkvm The kvm_openfiles/kvm_open functions now mark the returned file descriptors close-on-exec in case set-user-ID/set-group-ID applications are careless. *** *** 1191,1194 If you find this document useful, and you want to, you may buy the author a beer. ! $FreeBSD: src/UPDATING,v 1.73.2.68.2.30 2002/10/26 21:11:30 gshapiro Exp $ --- 1197,1200 If you find this document useful, and you want to, you may buy the author a beer. ! $FreeBSD: src/UPDATING,v 1.73.2.68.2.32 2003/01/06 12:38:21 nectar Exp $ Index: contrib/bind/CHANGES === RCS file: /home/ncvs/src/contrib/bind/CHANGES,v retrieving revision 1.1.1.7.2.6.2.1 retrieving revision 1.1.1.7.2.6.2.2 diff -c -r1.1.1.7.2.6.2.1 -r1.1.1.7.2.6.2.2 *** contrib/bind/CHANGES15 Jul 2002 07:51:02 - 1.1.1.7.2.6.2.1 --- contrib/bind/CHANGES14 Nov 2002 03:18:40 - 1.1.1.7.2.6.2.2 *** *** 1,3 --- 1,23 + 1469. [bug] buffer length calculation for PX was wrong. + + 1468. [bug] ns_name_ntol() could overwite a zero length buffer. + + 1467. [bug] off by one bug in ns_makecannon(). + + 1466. [bug] large ENDS UDP buffer size could trigger a assertion. + + 1465. [bug] possible NULL pointer dereference in db_sec.c + + 1464. [bug] the buffer used to construct the -ve record was not + big enough for all possible SOA records. use pointer + arithmetic to calculate the remaining size in this + buffer. + + 1463. [bug] use serial space arithmetic to determine if a SIG is + too old, in the future or has internally constistant + times. + + 1462. [bug] write buffer overflow in make_rr(). --- 8.3.3-REL released --- (Wed Jun 26 21:15:43 PDT 2002) Index: contrib/bind/bin/named/db_defs.h === RCS file: /home/ncvs/src/contrib/bind/bin/named/db_defs.h,v retrieving revision
Re: Kerberos OpenSSH+GSSAPI problem
You mailed me personally; you mailed the MIT Kerberos list; and you cross-posted on (at least) two FreeBSD mailing lists, all at approximately the same time. Please don't do that: it is rude. At least wait for replies in one area before launching into another. Cheers, -- Jacques A. Vidrine [EMAIL PROTECTED] http://www.celabo.org/ NTT/Verio SME . FreeBSD UNIX . Heimdal Kerberos [EMAIL PROTECTED] . [EMAIL PROTECTED] . [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: help compiling propolice gcc
On Sun, Dec 08, 2002 at 05:22:24PM -0800, Lamont Granquist wrote: I'm trying to follow these instructions to build 4.7 with the propolice modifications to the gcc compiler: http://www.trl.ibm.com/projects/security/ssp/buildfreebsd.html I'm starting with an absolutely fresh cvs checkout and i've nuked my /usr/obj tree. What I'm getting is in this step: You can't use IBM's procedure without a /usr/obj. Do a `make buildworld'. Cheers, -- Jacques A. Vidrine [EMAIL PROTECTED] http://www.celabo.org/ NTT/Verio SME . FreeBSD UNIX . Heimdal Kerberos [EMAIL PROTECTED] . [EMAIL PROTECTED] . [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: FreeBSD Developer Status Report: July 2002 - August 2002
On Thu, Oct 03, 2002 at 01:28:51PM -0700, Gregory Sutter wrote: On 2002-10-03 15:38 -0400, Robert Watson [EMAIL PROTECTED] wrote: July - August 2002 Status Report -- FreeBSD Security Officer Team URL: http://www.freebsd.org/security/ Contact: Jacques Vidrine [EMAIL PROTECTED] In September, the FreeBSD Security Officer published a new PGP key (ID 0xCA6CDFB2, found on the FTP site and in the Handbook). This aligned the set of those who possess the corresponding private key with the membership of the security-officer alias published on the FreeBSD Security web site. It also worked around an issue with the deprecated PGP key being found corrupted on some public key servers. The key in the published handbook remains: pub 1024R/73D288A5 1996-04-22 FreeBSD Security Officer [EMAIL PROTECTED] This was verified from the www copy of the handbook as well as the FTP site. The key is also unavailable from pgpkeys.mit.edu. Where can I get this new key? Sorry for the confusion. The new key was expected to be published, but there remain some minor unresolved issues with regard to key signatures. There was a comment in the submitted report, but I don't think it was read. I shouldn't have counted on that :-) Cheers, -- Jacques A. Vidrine [EMAIL PROTECTED] http://www.celabo.org/ NTT/Verio SME . FreeBSD UNIX . Heimdal Kerberos [EMAIL PROTECTED] . [EMAIL PROTECTED] . [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: kern/30712: fatal kernel trap during ufs_rename
Hello,
Does this ring any bells with anyone? This issue still exists with
FreeBSD 4.5-STABLE (4.6-PRERELEASE) and can be triggered on SMP
machines e.g. by having several process attempting to
create/rename/remove the same directory entry.
Cheers,
--
Jacques A. Vidrine [EMAIL PROTECTED] http://www.nectar.cc/
NTT/Verio SME . FreeBSD UNIX . Heimdal Kerberos
[EMAIL PROTECTED] . [EMAIL PROTECTED] . [EMAIL PROTECTED]
On Sat, Sep 22, 2001 at 04:31:38AM +0800, Yevgeniy Aleynikov wrote:
Number: 30712
Category: kern
Synopsis: fatal kernel trap during ufs_rename
Confidential: no
Severity: serious
Priority: high
Responsible:freebsd-bugs
State: open
Quarter:
Keywords:
Date-Required:
Class: sw-bug
Submitter-Id: current-users
Arrival-Date: Fri Sep 21 13:30:01 PDT 2001
Closed-Date:
Last-Modified:
Originator: Yevgeniy Aleynikov
Release:RELENG_4
Organization:
Infospace
Environment:
FreeBSD myserver.mydomain.net 4.3-MYTAG FreeBSD 4.3-MYTAG #0: Thu Sep 20 01:24:53
GMT 2001 [EMAIL PROTECTED]:/usr/src/sys/compile/config i386
Description:
Currently two independed computers hit that problem.
Machine is stanard 1Xtreme boxes shipped by BSDi. DualP3, i440Gx, intel MB, onboard
adaptec SCSI, connected to winchester RAID box.
Here what i've got:
gdb -k /kernel.debug vmcore.4
GNU gdb 4.18
SMP 2 cpus
IdlePTD 3039232
initial pcb at 2666a0
panicstr: ufs_rename: lost dir entry
panic messages:
---
panic: ufs_rename: lost dir entry
mp_lock = 0101; cpuid = 1; lapic.id =
boot() called on cpu#1
syncing disks... 16 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1
giving up on 1 buffers
Uptime: 16h20m39s
... skipped...
How-To-Repeat:
Not sure.
Fix:
Couldnt figure out what's wrong.
Release-Note:
Audit-Trail:
Unformatted:
bt
#0 dumpsys () at ../../kern/kern_shutdown.c:473
473 ../../kern/kern_shutdown.c: No such file or directory.
(kgdb) bt
#0 dumpsys () at ../../kern/kern_shutdown.c:473
#1 0xc015e9df in boot (howto=256) at ../../kern/kern_shutdown.c:313
#2 0xc015ede0 in poweroff_wait (junk=0xc0233c84, howto=-535697984)
at ../../kern/kern_shutdown.c:581
#3 0xc01c2239 in ufs_rename (ap=0xdf4fde60) at ../../ufs/ufs/ufs_vnops.c:1237
#4 0xc01c363d in ufs_vnoperate (ap=0xdf4fde60)
at ../../ufs/ufs/ufs_vnops.c:2382
#5 0xc019143b in rename (p=0xdf4c8740, uap=0xdf4fdf80) at vnode_if.h:645
#6 0xc0205011 in syscall2 (frame={tf_fs = 47, tf_es = 47, tf_ds = 47,
tf_edi = 134590624, tf_esi = 135163912, tf_ebp = -1077937980,
tf_isp = -548413484, tf_ebx = 672122988, tf_edx = 134600160, tf_ecx = 0,
tf_eax = 128, tf_trapno = 22, tf_err = 2, tf_eip = 672621324,
tf_cs = 31, tf_eflags = 659, tf_esp = -1077938040, tf_ss = 47})
at ../../i386/i386/trap.c:1155
#7 0xc01f291b in Xint0x80_syscall ()
#8 0x2807e125 in ?? ()
#9 0x280e7f0c in ?? ()
#10 0x8048e91 in ?? ()
#11 0x8048d7d in ?? ()
(kgdb)
This is from 19 sep. snapshot kernel. I had exactly the same problem with Jul 10
snapshot.
fsck didnt find anything wrong in filesystem.
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-bugs in the body of the message
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: Security through obscurity? (was: ssh + compiled-in SKEY support considered harmful?)
On Thu, Apr 25, 2002 at 12:02:59PM +0930, Greg 'groggy' Lehey wrote: I think it would be better to just put `-nolisten tcp' in /usr/X11R6/lib/X11/xinit/xserverrc for new installations only. Then the system administrator could easily override it for all users; and at least a user can override it for herself. If he knew about it. It's the old documentation trick. Look at my last message to Terry: we're talking about a package we don't control here. If somebody comes to FreeBSD from another system and X doesn't work the way he expects, he'll blame FreeBSD, not X. Well then we are sunk. I object to breaking currently working installations. I think it's OK to use better defaults for new installations. This is a hard issue for me to argue, because I consider this particular change to be of questionable value. Disclosure: I'm unhappy that after upgrading my laptop yesterday, I found I couldn't run `x2x', Because of this issue? Right. and had to restart my X session to remedy the problem. At least you knew what the problem was. Well, I've been running X for 10+ years. I guess I know what to look for. Cheers, -- Jacques A. Vidrine [EMAIL PROTECTED] http://www.nectar.cc/ NTT/Verio SME . FreeBSD UNIX .Heimdal Kerberos [EMAIL PROTECTED] . [EMAIL PROTECTED] . [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Security through obscurity? (was: ssh + compiled-in SKEY support considered harmful?)
On Wed, Apr 24, 2002 at 09:06:55AM +0930, Greg 'groggy' Lehey wrote: I think the issue here is that individuals make this kind of decision. We need a broader consensus for this kind of change. As Jochem points out, only 3 people were involved in the decision, all of them people with security profiles which weren't affected by this change. What, he should have gotten 30 reviewers? I think what is happening here is exactly what should happen: it seems like a good idea to one guy; he implements it. He shows it to a few more folks; they think it is a good idea, too. It gets committed, and the majority of people either don't notice it or believe it is a good feature. But the majority doesn't rule. The feature sits in the tree and maybe people run into problems with it. If so, it gets fine tuned or backed out. I think this is what is supposed to happen. For my part, I would like to see the change backed out and rethought. I like having the X server not doing TCP by default, but this change loses because: = It breaks existing configurations with no warning. = The option is in the wrong place (startx) and there is apparently no way to override the default. I think it would be better to just put `-nolisten tcp' in /usr/X11R6/lib/X11/xinit/xserverrc for new installations only. Then the system administrator could easily override it for all users; and at least a user can override it for herself. Disclosure: I'm unhappy that after upgrading my laptop yesterday, I found I couldn't run `x2x', and had to restart my X session to remedy the problem. All my X traffic uses IPsec --- there's no need to bring up SSH. Cheers, -- Jacques A. Vidrine [EMAIL PROTECTED] http://www.nectar.cc/ NTT/Verio SME . FreeBSD UNIX . Heimdal Kerberos [EMAIL PROTECTED] . [EMAIL PROTECTED] . [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: Older releases? was Re: FreeBSD Security Advisory FreeBSD-SA-02:21.tcpip
On Fri, Apr 19, 2002 at 09:59:14AM -0500, D J Hawkey Jr wrote: Developers: Userland is affected here - /usr/lib/libz. Would a make make install (sic) in /usr/src/lib/libz before building the kernel suffice for a solid upgrade? No, the src/lib/libz is --- as you note --- for userland. It is not used by the kernel. Note that the patch includes updates to the kernel source as well. Also note that `savecore' statically links libz, so it must be recompiled and reinstalled also. I don't believe there are any other programs in the base system that statically link libz. Cheers, -- Jacques A. Vidrine [EMAIL PROTECTED] http://www.nectar.cc/ NTT/Verio SME . FreeBSD UNIX . Heimdal Kerberos [EMAIL PROTECTED] . [EMAIL PROTECTED] . [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: C vs C++
[This is probably -chat material ...] On Wed, Mar 06, 2002 at 09:38:42PM -0600, Mike Meyer wrote: That is true. C++ is as ugly as C, but has all the problems of Object Orient Languages. I love this quote (from http://www.paulgraham.com/noop.html): Object-oriented programming generates a lot of what looks like work. Back in the days of fanfold, there was a type of programmer who would only put five or ten lines of code on a page, preceded by twenty lines of elaborately formatted comments. Object-oriented programming is like crack for these people: it lets you incorporate all this scaffolding right into your source code. -- Jacques A. Vidrine [EMAIL PROTECTED] http://www.nectar.cc/ NTT/Verio SME . FreeBSD UNIX .Heimdal Kerberos [EMAIL PROTECTED] . [EMAIL PROTECTED] . [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: cvs commit: src/share/termcap termcap.src
Andrey also said: Maybe you have to add AX too, if 39m 49m can be issued separately. I can't tell whether rxvt supports this (AX) capability. Can someone suggest a test? Cheers, -- Jacques A. Vidrine [EMAIL PROTECTED] http://www.nectar.cc/ NTT/Verio SME . FreeBSD UNIX . Heimdal Kerberos [EMAIL PROTECTED] . [EMAIL PROTECTED] . [EMAIL PROTECTED] On Wed, Jan 09, 2002 at 05:13:51AM -0800, Jacques Vidrine wrote: nectar 2002/01/09 05:13:51 PST Modified files: share/termcaptermcap.src Log: Fix the rxvt termcap entry: = Get the alternate character set capabilities right. = Enable color support for `rxvt'. = Add `rxvt-mono' for no color support. Approved by:ache Revision ChangesPath 1.116 +6 -2 src/share/termcap/termcap.src To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
evolution sigreturn: eflags = 0x246
Hi, I decided to give Evolution a try. It seems that with large mail folder (via Maildir or IMAP), the mail component dies (signal 6). I notice the following: Dec 7 09:24:56 madman /kernel: sigreturn: eflags = 0x246 Dec 7 09:24:56 madman /kernel: pid 56881 (evolution-mail), uid 1001: exited on signal 6 The sigreturn message is generated inside of `sigreturn', around line 947 on sys./i386/i386/machdep.c (in 4.4-RELEASE). This code is unfamiliar to me, but I suspect that there is a bug in Evolution's signal handling that is causing corruption of the signal context. I thought I'd ask for a second opinion before trying to track it down. Has anyone else seen this with Evolution, or something similar with another application? Cheers, -- Jacques A. Vidrine [EMAIL PROTECTED] http://www.nectar.cc/ NTT/Verio SME . FreeBSD UNIX .Heimdal Kerberos [EMAIL PROTECTED] . [EMAIL PROTECTED] . [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: cvs commit: src/lib/libc/net rcmdsh.3 rcmdsh.c Makefile.inc rcmd.c
On Mon, Oct 22, 2001 at 11:22:15PM -0700, Warner Losh wrote: imp 2001/10/22 23:22:15 PDT Modified files: lib/libc/net Makefile.inc rcmd.c Added files: lib/libc/net rcmdsh.3 rcmdsh.c Log: Allow users to specify a command to use as remote command instead of using rcmd directly. This has been in my tree for a long time, but we may need to sync with OpenBSD before MFC. Obtained from: openbsd PR: 15830 MFC after: 2 months Yay! Does this mean one can use ssh with dump/restore now? -- Jacques A. Vidrine [EMAIL PROTECTED] http://www.nectar.com/ Verio Web Hosting = FreeBSD UNIX =Heimdal Kerberos [EMAIL PROTECTED] = [EMAIL PROTECTED] = [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: cvs commit: src/lib/libc/net rcmdsh.3 rcmdsh.c Makefile.inc rcmd.c
On Tue, Oct 23, 2001 at 07:16:38AM -0700, Seth Kingsley wrote: On Tue, Oct 23, 2001 at 07:56:26AM -0500, Jacques A. Vidrine wrote: Yay! Does this mean one can use ssh with dump/restore now? Since when couldn't you just use: ssh host dump -b 8 -f - | dd bs=8k file and similar for restore? Think about what happens if your filesystem cannot fit on a single volume. -- Jacques A. Vidrine [EMAIL PROTECTED] http://www.nectar.com/ Verio Web Hosting = FreeBSD UNIX =Heimdal Kerberos [EMAIL PROTECTED] = [EMAIL PROTECTED] = [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: OpenSSH + Kerberos 5 + PAM
On Wed, Aug 29, 2001 at 11:37:18PM -0500, Jim Bryant wrote: I'm not that current on krb5, but I do have to ask if the CERT issues have been resolved? My info on this is a little old, but I recall CERT advisories last year on serious vulnerabilities in krb5 at the time, it would be nice to know if they have been fixed. Do you think you could be a little more specific? AFAIK, there are no publicly known, unfixed vulnerabilities in either MIT or Heimdal Kerberos. Cheers, -- Jacques Vidrine / [EMAIL PROTECTED] / [EMAIL PROTECTED] / [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
inet6 address host - network order
What's the most portable way of converting an IPv6 address from host to network order? Cheers, -- Jacques Vidrine / [EMAIL PROTECTED] / [EMAIL PROTECTED] / [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: inet6 address host - network order
On Tue, Aug 21, 2001 at 09:37:49AM -0500, Jacques A. Vidrine wrote: What's the most portable way of converting an IPv6 address from host to network order? Nothing like following up your own post. RFC 2553 indicates that the IPv6 address is stored in the `struct in6_addr' in network byte order, so there shouldn't be any need to swap bytes. Cheers, -- Jacques Vidrine / [EMAIL PROTECTED] / [EMAIL PROTECTED] / [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: libc.a(err.o)
On Wed, Jul 25, 2001 at 01:21:18AM -0500, Hal Snyder wrote: I am wondering if there is a problem with err, warn, etc. in libc. [snip] Bug? Feature? Do we want separate modules? Weak symbols? Yes, it is a bug. IMHO we should be using weak symbols for all globally visibile identifiers in libc that are not defined by ISO/IEC 9899:199[09]. This comes up periodically; check the archives. Basically somebody needs to do the work. Cheers, -- Jacques Vidrine / [EMAIL PROTECTED] / [EMAIL PROTECTED] / [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: nsswitch dynamically loadable modules
On Sun, Jun 10, 2001 at 08:14:57PM +0200, Gyori Sandor wrote: [snip] By applying these patches (nsswitch nss_ldap) did you get a proper working authentication via LDAP? I applied them, but system doesn't know LDAP's user names. This is my fault or I should even not try this way? I didn't `apply' these patches -- I generated the patches. And yes, it worked for me at the time. However, as I already stated, that was a throw-away implementation and I did not keep them in sync with FreeBSD. So perhaps they are broken with regards to -STABLE today, or perhaps you have something misconfigured in LDAP. May I see this code anywhere? I can't find info about above way on your homepage. I have not made it publicly available. It would not do you any good anyway, as it is not complete. Cheers, -- Jacques Vidrine / [EMAIL PROTECTED] / [EMAIL PROTECTED] / [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: nsswitch dynamically loadable modules
On Sun, Jun 10, 2001 at 05:17:23PM -0700, Peter Wemm wrote: This is probably why it wont be committed. If it uses dlopen() then it cannot work for the statically linked /bin/ls, /bin/sh, etc. Anything in / sbin or /bin will never be able to see the usernames. If you built the entire system with NOSHARED=NO, then /bin/ls, /bin/sh etc will be dynamically linked and the patches will probably work. However, you had better have /usr on your root (/) file system or you wont be able to boot. Linux's solution is to put the ld.so and libc.so onto the / partition in /lib. This is the evolution I have in mind: nsswitch static only (FreeBSD-CURRENT today) | V nsswitch w/static support for files, dns, nis; modules can be added for other sources; these modules may be compiled statically as part of libc, but would generally be loaded dynamically (this is roughly the stage the prototype was at) | V `module' implementing stubs to communicate with an external process; the external process itself can dynamically load other modules (this is my target before my next commit to -CURRENT) | V (finished) the stub/external process module is a standard way of providing additional sources, giving three ways to `link' in modules: static, dynamic, stub The static stub cases would support all executables; the dynamic case of course would only be available for dynamically-linked executables. Supporting the `stub' case was the primary cause for designing a new nsdispatch() API. Cheers, -- Jacques Vidrine / [EMAIL PROTECTED] / [EMAIL PROTECTED] / [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: nsswitch dynamically loadable modules
On Sun, Jun 10, 2001 at 06:24:58PM +0200, Gyori Sandor wrote: 1. I don't understand exactly why, but even into -CURRENT there was implemented only the statical part of nsswitch. Please search the archives for full information. Here is the history in summary: = I ported NetBSD's nsswitch implementation to FreeBSD-CURRENT. It only implements files, NIS, and Hesiod. It does not support dynamically loaded sources. = I extended the implementation to support dynamically loaded sources, and ported nss_ldap to use the invented interface. These are the patches you referred to. This was a prototype to help me understand the issues. They will never be committed, and should not be used in production. = I re-did the implementation using a design that I am happy with, and interfaces which are agreed-upon-in-principal with the NetBSD nsswitch author. In addition to new interfaces, this new implementation is reentrant (although YP and our resolver is not). A major design goal was to enable the creation of modules that are stubs which talk to a long-running daemon that does the hard work. PADL.COM's nss_ldap is (IMHO) completely unsuitable for a production environment, particularly if you use SSL. = Eventually I will finish the implementation just described. Left to do is updating some resolver-oriented stuff like getaddrinfo, and (importantly) creating an nsswitch-ldap daemon. If someone wants to work on this stuff, I would be happy to hand it off after we had sufficient discussion so that I was confident the design was understood. Otherwise, please wait. I wish I had finished it sooner, but that's how it goes. Cheers, -- Jacques Vidrine / [EMAIL PROTECTED] / [EMAIL PROTECTED] / [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: free() and const warnings
On Sat, Jun 09, 2001 at 12:49:40AM -0700, Damien Neil wrote: On Thu, Jun 07, 2001 at 12:47:30PM -0500, Jacques A. Vidrine wrote: C99 says of uintptr_t only that for any valid pointer p, the following is true: (void *)(uintptr_t)p == (void *)p Likewise for intptr_t. I read that as covering both code and data pointers. C89, at least, does not guarantee that you can convert between code and data pointers. I believe the same holds for C99. Agreed. The original point was whether or not a uintptr_t was big enough for both types of pointers. Cheers, -- Jacques Vidrine / [EMAIL PROTECTED] / [EMAIL PROTECTED] / [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: free() and const warnings
On Thu, Jun 07, 2001 at 10:20:51AM -0700, John Baldwin wrote: On 07-Jun-01 Peter Pentchev wrote: On Thu, Jun 07, 2001 at 07:07:22PM +0300, Peter Pentchev wrote: Hi, Is free((void *) (size_t) ptr) the only way to free a const whatever *ptr with WARNS=2? (or more specifically, with -Wcast-qual) Uhm. OK. So size_t may not be enough to hold a pointer. What is it then - caddr_t? uintptr_t for data pointers. In theory I think code pointers may not fit in a uintptr_t. C99 says of uintptr_t only that for any valid pointer p, the following is true: (void *)(uintptr_t)p == (void *)p Likewise for intptr_t. I read that as covering both code and data pointers. Of course, who's to say the way uintptr_t is implemented on our platform adheres to the same rules :-) free((void *)(uintptr_t)ptr) should work. Of course, this begs the question of why you are free'ing a const. :) Indeed! Cheers, -- Jacques Vidrine / [EMAIL PROTECTED] / [EMAIL PROTECTED] / [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: MFC'ing new md(4) functionality?
On Mon, Jun 04, 2001 at 07:46:18PM -0700, Dima Dorfman wrote: mdconfig(8) and mdioctl.h aren't in -stable so those can be brought over verbatim, Dumb question: Can we just add a RELENG_4 tag to the files in such a case? Cheers, -- Jacques Vidrine / [EMAIL PROTECTED] / [EMAIL PROTECTED] / [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: nsswitch progress
On Wed, May 30, 2001 at 06:54:10AM +1000, Chris Knight wrote: If someone with commit privs is interested, I have a set of patches based on the 4.1-STABLE patches that apply cleanly to 4.3. This should be slightly quicker to merge with -STABLE. Are these patches equivalent to the functionality in -CURRENT (i.e. straight port of the NetBSD code: files, NIS, Hesiod only)? Or are they based on what is found on my web page today (i.e. prototype with dynamic linking, reentrant interfaces, nss_ldap support)? If the former, I wouldn't mind if they were committed if the rest of the world wants it. If the latter, that should not be committed to -STABLE under any circumstances, and probably not to -CURRENT either (else I would have done it, instead of putting it off until I could complete the work). Cheers, -- Jacques Vidrine / [EMAIL PROTECTED] / [EMAIL PROTECTED] / [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: nsswitch progress
On Mon, May 28, 2001 at 06:00:51PM +0200, Eric Masson wrote: Hello, Few months ago, Jacques Vidrine [EMAIL PROTECTED] posted mails about implementation of nsswitch in -current. Is there any progress in this area ? If so, any hope to see a MFC ? Hello, I've only been slowly working on nsswitch this year, as I'm occupied on other projects. I intend to return to it and complete it as soon as possible. Much new work has been done, but there is quite a bit of tedium left. I will be very disappointed if I am not able to complete the work before 5.0-RELEASE. I have no plans to do a MFC of the existing implementation, because the API and functionality has changed from what I've committed to -CURRENT, and indeed from the last set of patches I publicly posted. I don't have any objections to an MFC -- after all, the current code is stable, and the API is the same as what is currently found in NetBSD. It just is not a priority for me. Most people want support for more than just files, NIS, and Hesiod. Cheers, -- Jacques Vidrine / [EMAIL PROTECTED] / [EMAIL PROTECTED] / [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: telnet to AF_UNIX sockets [PATCH]
On Thu, May 24, 2001 at 12:56:28PM -0600, Lyndon Nerenberg wrote: As a more general solution I have an inetd that groks AF_UNIX. You would have to add chroot/jail support to it, though, and some would argue that that's making inetd a bit featureful. I dunno. Somehow it makes more sense to me than adding AF_UNIX support to telnet. -- Jacques Vidrine / [EMAIL PROTECTED] / [EMAIL PROTECTED] / [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: telnet to AF_UNIX sockets [PATCH]
On Thu, May 24, 2001 at 01:24:03PM -0700, Matt Dillon wrote: :Because `all telnet really does is connect to sockets' is patently :false. Check out the nearly 100 RFCs detailing the TELNET protocol. :Almost none of these make much sense to do over UNIX domain sockets :[1]. Huh? Oh yah, *that* protocol. Telnet only does that if the server is a telnetd. Otherwise it's just straight character I/O. What I am saying is that we really should have a separate app to do `just straight character I/O' over whatever medium. There are already several in the ports tree. Any experienced sysad knows this from telneting to the web server or smtp server or pop server, etc etc etc. Being able to telnet to a unix domain socket is no different. I don't often use telnet for this. Rather, I use netcat. I do recognize that other folks do this. In practice, no harm comes of it. In principal, I think it is silly to try to talk TELNET with something that you know shouldn't be talking TELNET. Unix domain sockets are a good test of experience. They are obscure enough that many people don't even realize they exist (and even fewer know that you can pass file descriptors over them). But unix-domain sockets are extremely useful in all manner of applications and the more sophisticated programmers use them all over the place. Being able to telnet to one is natural. Over the years I've probably written the 'connect to unix domain socket' program 50 times because it wasn't standard in a system. Now it is. Yahhh. I agree with the sentiment here. I just don't agree with sticking it in telnet. Perhaps paradoxically, I wouldn't mind so much if inetd + telnetd were updated to support PF_UNIX, too. Then, at least, there would be something to talk NVT to over PF_UNIX :-) But as the original submittor said, this thread is getting silly. I merely wanted to note my objection, not argue about it. I should have also noted that I would have liked /some/ discussion of this on freebsd-net before it was committed, but hey, it's -CURRENT. Cheers, -- Jacques Vidrine / [EMAIL PROTECTED] / [EMAIL PROTECTED] / [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: gcc (cpp) include search path problem
[This is most likely a ports issue, so kicked to -ports]
On Fri, May 25, 2001 at 10:56:42PM +0300, Peter Pentchev wrote:
On second thoughts, you might have a problem if you are trying to
install the wget port in a location other than /usr/local.
If you change PREFIX, then the -I{PREFIX}/include directive would
point to the location you want to install wget at, not at /usr/local.
In that case, the proper course of action would be to first install
the devel/gettext port into the same location (using the same value
of PREFIX); then, its include files would be in ${PREFIX}/include,
its libraries would be in ${PREFIX}/lib, and wget would build just fine.
No, this is not really correct. When ports are looking for other
installed ports, they should use ${LOCALBASE} or ${X11BASE} as
appropriate, not ${PREFIX}. In other words, the wget port should
probably specify -I${LOCALBASE}/include instead of/in addition to
-I${PREFIX}/include.
Cheers,
--
Jacques Vidrine / [EMAIL PROTECTED] / [EMAIL PROTECTED] / [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-hackers in the body of the message
Re: telnet to AF_UNIX sockets [PATCH]
[cc: trimmed] On Thu, May 24, 2001 at 11:10:10AM -0700, Gordon Tetlow wrote: It depends on how you look at it. If you see telnet as a network client, then you cringe at this (I did initially). But when you think about it, all telnet really does is connect to sockets, so why not extend its functionality to local sockets? Because `all telnet really does is connect to sockets' is patently false. Check out the nearly 100 RFCs detailing the TELNET protocol. Almost none of these make much sense to do over UNIX domain sockets [1]. A small tool that `just connects to sockets' would certainly be handy. However, that's why there are things such as netcat. Cheers, -- Jacques Vidrine / [EMAIL PROTECTED] / [EMAIL PROTECTED] / [EMAIL PROTECTED] [1] I think it was Peter who did mention one application of this (NVT over AF_UNIX), which would be for communication with `jails'. This is pretty specialized, and requires a telnet daemon that listens on AF_UNIX as well. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: telnet to AF_UNIX sockets [PATCH]
On Wed, May 23, 2001 at 08:10:20PM -0400, James Howard wrote: I am missing something here. Is there a practical use for this? :) You are not the only one. I can appreciate the `neat' factor, but I cringed at the commit. It seems like functionality that would be better put in a separate utility (or port even). It's not like you'd ever want to run the NVT protocol over an AF_UNIX socket. -- Jacques Vidrine / [EMAIL PROTECTED] / [EMAIL PROTECTED] / [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-hackers in the body of the message
Re: cvs commit: src/kerberos5/usr.bin Makefile src/kerberos5/usr.bin/k5su Makefile
On Mon, Mar 05, 2001 at 03:18:35AM -0800, Mark Murray wrote: markm 2001/03/05 03:18:35 PST Modified files: kerberos5/usr.binMakefile Added files: kerberos5/usr.bin/k5su Makefile Log: *Sigh*. What I did without this, I have no idea. Will we always have this dichotomy between kblah/k5blah utilities? It is fairly annoying. Anecdotally, there don't seem to be many new Kerberos IV installations, Kerberos V's utilities can get/list/trash version 4 5 tickets. Curious, -- Jacques Vidrine / [EMAIL PROTECTED] / [EMAIL PROTECTED] / [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Heimdal and pam_kerberos5 (was Re: cvs commit: src/kerberos5/usr.bin [...])
On Mon, Mar 05, 2001 at 03:20:18PM +0100, Assar Westerlund wrote:
"Jacques A. Vidrine" [EMAIL PROTECTED] writes:
Will we always have this dichotomy between kblah/k5blah utilities? It is
fairly annoying. Anecdotally, there don't seem to be many new Kerberos
IV installations, Kerberos V's utilities can get/list/trash version 4
5 tickets.
Yes. My current plan of things to happen (in -current and after 4.3)
is to ditch the v4 programs basically and install the v5 ones under
the canonical names (with v4-compatibility if compiled in). And to
always build and install the krb5 programs/libraries, but ifdef'ing
the support in other programs. How does that sounds?
That's what I wanted to hear :-)
By the way. In my faithlessness, I did not expect that 0.3e would be
MFC'd in time for 4.3. I'm pleasantly surprised. However, I would be
sorry that 4.3 shipped without a pam_kerberos5. I am preparing to
leave on holiday, and will not be able to make it happen myself. In
the hopes that someone else can pick up the pieces, I am attaching a
shar that I threw together today. I'm pretty sure that I don't have
the dependencies right, but I can't play with a build world at the
moment.
This contains a pam_kerberos5 module derived from fcusack's (as found
in ports/security/pam_krb5). Unfortunately, it does not appear that
fcusack is maintaining this. I've been maintaining it on an
unofficial basis, initially fixing several bugs and getting it to
build with Heimdal, and then integrating fixes from the Kerberos
mailings lists. In fact, some Linux distributions now apparently use
this `version' from ports/security/pam_krb5.
In short, I think it is appropriate to add it to the source tree so
that it will be maintained. The license is dual BSD/GPL. If this
misses 4.3 it is not the end of the world, but it would be nice. I've
been using the port with consoles, sshd, and xdm (actually wdm) for
four months or so.
Cheers,
--
Jacques Vidrine / [EMAIL PROTECTED] / [EMAIL PROTECTED] / [EMAIL PROTECTED]
# This file contains patches and a shar archive. I expect it to
# be invoked as follows:
#
# % (cd /usr/src /bin/sh ${HOME}/pam_kerberos5.shar)
#
echo p - share/mk/bsd.libnames.mk
(sed 's/^X//' |/usr/bin/patch -Ns) 'END-of-share/mk/bsd.libnames.mk'
X--- share/mk/bsd.libnames.mk.orig Sun Mar 4 10:16:23 2001
X+++ share/mk/bsd.libnames.mk Mon Mar 5 11:37:33 2001
X@@ -10,6 +10,7 @@
X LIBKZTAIL?= ${DESTDIR}${LIBDIR}/kztail.o
X
X LIBALIAS?=${DESTDIR}${LIBDIR}/libalias.a
X+LIBASN1?= ${DESTDIR}${LIBDIR}/libasn1.a # XXX in secure dist, not base
X LIBATM?= ${DESTDIR}${LIBDIR}/libatm.a
X LIBC?=${DESTDIR}${LIBDIR}/libc.a
X LIBC_PIC= ${DESTDIR}${LIBDIR}/libc_pic.a
X@@ -35,12 +36,14 @@
X LIBGCC_PIC?= ${DESTDIR}${LIBDIR}/libgcc_pic.a
X LIBGMP?= ${DESTDIR}${LIBDIR}/libgmp.a
X LIBGNUREGEX?= ${DESTDIR}${LIBDIR}/libgnuregex.a
X+LIBGSSAPI?= ${DESTDIR}${LIBDIR}/libgssapi.a # XXX in secure dist, not base
X LIBHISTORY?= ${DESTDIR}${LIBDIR}/libhistory.a
X LIBIPSEC?=${DESTDIR}${LIBDIR}/libipsec.a
X LIBIPX?= ${DESTDIR}${LIBDIR}/libipx.a
X LIBISC?= ${DESTDIR}${LIBDIR}/libisc.a
X LIBKDB?= ${DESTDIR}${LIBDIR}/libkdb.a# XXX in secure dist, not base
X LIBKRB?= ${DESTDIR}${LIBDIR}/libkrb.a# XXX in secure dist, not base
X+LIBKRB5?= ${DESTDIR}${LIBDIR}/libkrb5.a # XXX in secure dist, not base
X LIBKEYCAP?= ${DESTDIR}${LIBDIR}/libkeycap.a
X LIBKVM?= ${DESTDIR}${LIBDIR}/libkvm.a
X LIBL?=${DESTDIR}${LIBDIR}/libl.a
X@@ -76,6 +79,7 @@
X LIBRADIUS?= ${DESTDIR}${LIBDIR}/libradius.a
X LIBREADLINE?= ${DESTDIR}${LIBDIR}/libreadline.a
X LIBRESOLV?= ${DESTDIR}${LIBDIR}/libresolv.a # XXX doesn't exist
X+LIBROKEN?=${DESTDIR}${LIBDIR}/libroken.a # XXX in secure dist, not base
X LIBRPCSVC?= ${DESTDIR}${LIBDIR}/librpcsvc.a
X LIBSCRYPT?= "don't use LIBSCRYPT, use LIBCRYPT"
X LIBDESCRYPT?= "don't use LIBDESCRYPT, use LIBCRYPT"
END-of-share/mk/bsd.libnames.mk
echo p - lib/libpam/modules/Makefile
(sed 's/^X//' |/usr/bin/patch -Ns) 'END-of-lib/libpam/modules/Makefile'
X--- lib/libpam/modules/Makefile.orig Sun Mar 4 10:37:31 2001
X+++ lib/libpam/modules/MakefileMon Mar 5 12:01:39 2001
X@@ -29,7 +29,7 @@
X .if defined(MAKE_KERBEROS4) !defined(NOCRYPT) !defined(NO_OPENSSL)
X SUBDIR+= pam_kerberosIV
X .endif
X-.if defined(MAKE_KERBEROS5__) !defined(NOCRYPT) !defined(NO_OPENSSL)
X+.if defined(MAKE_KERBEROS5) !defined(NOCRYPT) !defined(NO_OPENSSL)
X SUBDIR+= pam_kerberos5
X .endif
X SUBDIR+= pam_opie
END-of-lib/libpam/modules/Makefile
# This is a shell archive. Save it in a file, remove anything before
# this line, and then unpack it by entering "sh file". Note, it may
# create directories; files and directories will be owned by you and
# have default permissions.
#
# This archive contains:
#
# lib/libpam/modules/pam_kerberos5
# lib/libpam/mo
Re: portability sanity check
On Wed, Feb 21, 2001 at 05:28:31PM +0100, Poul-Henning Kamp wrote: Type-safety is a cruch for the weak-minded. ^ As an old assembler programmer I couldn't agree more, but in a project like FreeBSD we have to realize that not everybody is that. Heh, I was just cleaning out these message from my inbox, and I discovered that spell-checkers are a crutch for the weak-minded, too :-) Thanks for everyone's feedback. I decided that I'm quite happy to use type-punning for more-or-less primitive types when building comparison functions and the like. For more complex stuff, it seems simplest/clearest to use a `void *' for internal data, a la db. Cheers, -- Jacques Vidrine / [EMAIL PROTECTED] / [EMAIL PROTECTED] / [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: portability sanity check
On Wed, Feb 21, 2001 at 09:56:08AM -0700, Warner Losh wrote: There is some verbage in the structure layout part of the standard that makes this a logical conclusion. However, it is overly tricky code. But then again to do the generic sort of thing you want to do, you have to resort to C macros, or other gross things to make it generic. The question becomes how do you do that in the least gross way... Someone will say ``Use C++'' here. Then I will ignite a copy of `The Annotated C++ Reference Manual' and hit them with it. I think using unions is actually out of the question if you want to be able to allow new `types' after compile time. When you say ``resort to C macros,'' do you mean macros to hide the `type punning', or do you have something else in mind? Cheers, -- Jacques Vidrine / [EMAIL PROTECTED] / [EMAIL PROTECTED] / [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: portability sanity check
On Wed, Feb 21, 2001 at 08:53:57AM -0700, Warner Losh wrote: The standard requires that (void *) foo == (void *) foo-s Thanks, that is what I was trying to track down but couldn't find it. I also thought that perhaps a structure has the same requirement alignments as its first member ... I think that means the same thing as you've stated. Cheers, -- Jacques Vidrine / [EMAIL PROTECTED] / [EMAIL PROTECTED] / [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: portability sanity check
On Wed, Feb 21, 2001 at 05:13:35PM +0100, Poul-Henning Kamp wrote:
In message [EMAIL PROTECTED], Warner Losh writes:
In message [EMAIL PROTECTED] "Jacques A. Vidrine" writes:
: Likewise if the first member were a more complex data type, but
: nevertheless the same between the different structures.
:
: It seems safe to me, but I can't explain why :-)
It is obfuscated 'C', but it is safe. The standard requires that
(void *) foo == (void *) foo-s and that if s were a complex
structure that it be laid out the same in all instances of s. So I
think that it is "safe" to do that.
Safe, but stupid, since type-safety is lost when doing so.
Type-safety is a cruch for the weak-minded.
:-)
But seriously I think that for the purpose of building a utility
function for use by qsort or similar, using a union just for such
a purpose is more obfuscated.
struct nothing_much_in_common_really {
const char *s;
union {
struct foo foo;
struct bar bar;
} u;
};
But if there is a better way, I'm all ears :-)
Cheers,
--
Jacques Vidrine / [EMAIL PROTECTED] / [EMAIL PROTECTED] / [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
portability sanity check
Is the following portable and safe?
Given n different structure declarations, where each structure begins
with the same member type, can any instance of any of the structures
be cast to the (pointer) type of the first member?
e.g.
struct foo {
const char *s;
...
};
struct bar {
const char *s;
...
};
int gefahr(struct foo *Foo, struct bar *Bar) {
return strcmp((const char *s)Foo, (const char *s)Bar);
}
Likewise if the first member were a more complex data type, but
nevertheless the same between the different structures.
It seems safe to me, but I can't explain why :-)
Cheers,
--
Jacques Vidrine / [EMAIL PROTECTED] / [EMAIL PROTECTED] / [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: Staticaly allocated buffers in library. Is it correct?
On Tue, Feb 20, 2001 at 06:14:42PM +0300, Andrey Simonenko wrote: Let's look at implementation of getaddrinfo(3) function (there are some functions more which do the same way). We can find source for this function in /usr/src/lib/libc/net/getaddrinfo.c file. This functions in some case reads /etc/hosts file and try to find out there host name. getaddrinfo(3) calls some functions and function _gethtent() tries to read line by linefrom /etc/hosts file: [snip code] We can see if line is bigger than 8k, then _gethtent() reads until the end of line. In most case this function doesn't find needed host name in such lines, but in some case it can find part of line as correct host name and tries to fetch IP address, but it also will not work, because we lose beginning of line when "goto again". This code can be simply rewriten as loop with fgets(), strlen()/strchr() and realloc(), but it causes speed lost in this function. Also I understand that 8k for line in /etc/hosts is enough and should not be problem for most of _real life_ situations. I'm coming in late in this thread. What is it you are trying to accomplish? FWIW, I've rewritten this and lots of code like it while revamping nsswitch. Unlike the traditional code, I am careful to handle lines of arbitrary length by processing only chunks (e.g. 512 bytes) at a time. Cheers, -- Jacques Vidrine / [EMAIL PROTECTED] / [EMAIL PROTECTED] / [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: [moebius@bitstream.net: 4.1.1-release ldconfig issue]
On Fri, Feb 16, 2001 at 09:34:22PM -0600, Maximus [EMAIL PROTECTED] wrote: I installed libiconv-1.5.1 on my 4.1.1-release system with the following results: -rw-r--r-- 1 root wheel 452 Feb 16 09:05 libiconv.la lrwxr-xr-x 1 root wheel 15 Feb 16 09:05 libiconv.so - libiconv.so.2.2 -rw-r--r-- 1 root wheel 646265 Feb 16 09:05 libiconv.so.2.2 ^^ ELF libraries should only have a major version, not a major+minor version. Install the port instead of compiling it yourself, and this will be handled. Once finished I run 'ldconfig -m /usr/local/lib /usr/lib'. No errors to this point. I believe that ELF ldconfig will ignore libraries with more than one version number tagged on. But it doesn't matter much -- the hints file is not used with ELF. Once done I run 'ldconfig -r | grep icon' and nothing is there. The library is not making it into the hints file. Running file on the .so.2.2 file I get the following: libiconv.so.2.2: ELF 32-bit LSB shared object, Intel 80386, version 1 (FreeBSD), not stripped Obviously I'm missing something. What? Any pointer would be appreciated. At the minimum, where would I find the source for ldconfig? Which package? Package? ldconfig is in the base system, and a good guess would be: $ which ldconfig /sbin/ldconfig $ cd /usr/src/sbin/ldconfig $ ls Makefileelfhints.c ldconfig.8 ldconfig.c ldconfig.h Hope this helps! Cheers, -- Jacques Vidrine / [EMAIL PROTECTED] / [EMAIL PROTECTED] / [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: [moebius@bitstream.net: 4.1.1-release ldconfig issue]
On Sat, Feb 17, 2001 at 12:41:25PM -0600, Maximus wrote: Wonderful...partly. This worked to get the lib in ldconfig, but then I noticed that it still couldn't find the lib. Well, as I said, the hints are not used for linking at all. Trussing 'ld -liconv' revealed that it was only looking in /usr/lib. I have a LD_LIBRARY_PATH, and even went so far as to create a LD_FLAGS var. Neither of these things made ld even glance beyond /usr/lib. LD_LIBRARY_PATH is not used at link time, only at run time. If you want additional paths to be searched for libraries, use the -L flag. You may want to read `info -f gcc' and/or `info -f ld' if you have further trouble. Cheers, -- Jacques Vidrine / [EMAIL PROTECTED] / [EMAIL PROTECTED] / [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: [kernel patch] fcntl(...) to close many descriptors
On Mon, Jan 29, 2001 at 03:13:05PM +0100, mouss wrote: I fully agree that we'd better mimic netbsd than aix... but the netbsd closeall() is just a libc function that calls close() for all descriptors. so we can still mimic it with: #define closeall(start) fcntl(start, F_CLOSEM, 0) Better a function than a macro. and with this, we have both netbsd and aix compat. note that if I do it for freebsd, I'll do the same for netbsd and openbsd (I'm a fan of *BSD convergence [I don't mean they should be the same, but unjustified diffs should be killed whenever possible]:). As for the "generic" syscall mechanism, I'd love it. I think that there are many places where "names" would be good, instead of hardcoded numbers. The only problem is to find a way to do that without reducing performance. names are good. just try to see what it would be if filenames were replaced by inodes. I think that having a name-based mechanism makes it easier to add new syscalls or reject deprecated ones. Performance is not much of an issue. A perfect hash can be generated for syscall names. [snip] back to the closeall, here is what I suggest: - add the fcntl option. the coherence arg is certainly reasonable, but fcntl is not a "cohrent" function (thanks to svr4 lobbying into posix:). - add a closeall macro to call it. this gives both aix and netbsd compat (and if the fcntl thing goes into netbsd, the compat would be full). I really do not care for using fcntl with this. fcntl operates on a single file descriptor -- F_CLOSEM mucks up the interface. -- Jacques Vidrine / [EMAIL PROTECTED] / [EMAIL PROTECTED] / [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: [kernel patch] fcntl(...) to close many descriptors
On Sun, Jan 28, 2001 at 10:37:16AM -0800, Luigi Rizzo wrote:
do we have (or could we design) a generic mechanism for machine-specific
syscalls which are not available on all OS ?
basically i am thinking of something like
generic_syscall("fdcloseall", );
Do you mean like syscall(2)?
--
Jacques Vidrine / [EMAIL PROTECTED] / [EMAIL PROTECTED] / [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: PAM (was: Re: MAIL set by whom?)
On Tue, Jan 23, 2001 at 02:42:41AM +0900, Daniel C. Sobral wrote: Ports shouldn't touch /etc. Does the existance of /etc/pam.conf precludes /usr/local/etc/pam.d from working? Other way around. From the man page (the last sentence is even underlined :-) Alternatively, the configuration can be set by individual configuration files located in the /etc/pam.d/ directory. The presence of this directory will cause PAM to ignore /etc/pam.conf. -- Jacques Vidrine / [EMAIL PROTECTED] / [EMAIL PROTECTED] / [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: [PATCH available] TI-RPC and NetBSD's rpc.lockd
On Tue, Dec 26, 2000 at 02:20:46AM +0100, Martin Blapp wrote: [snip] Issues with the code: 1.) NETBSD sets in svc_tcp.c some LOCAL_CREDS which we don't have in our src/sys/kern/uipc_usrreq.c. They have a FLAG which - if set - automatically sends the credentials on AF_UNIX sockets connections if we do a recvmsg(). We have to implement this to have rpcbind properly working. AF_UNIX socket operations are broken at the moment, but with compability-mode 'rpcbind -Li' rpcbind works. We have something analogous ... look for SCM_CREDS. It's a shame these aren't the same on both (Net|Free)BSD. To narrow it down for you, here are the relevant files in -CURRENT: src/sys/kern/uipc_usrreq.c src/lib/libc/rpc/clnt_unix.c src/lib/libc/rpc/svc_unix.c keyserv and rpc.yppasswd are example applications that use this feature. -- Jacques Vidrine / [EMAIL PROTECTED] / [EMAIL PROTECTED] / [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: [PATCH available] TI-RPC and NetBSD's rpc.lockd
On Tue, Dec 26, 2000 at 03:33:53PM -0800, Bill Paul wrote: I'm responsible for implementing this feature. Thanks for that! Using the SCM_CREDS 'hack' was a) expedient, as it only involved a minor change to the kernel and b) it seemed to agree with the way RPC worked, i.e. each RPC needs the credential info for authentication. Anyway, imagine my surprise when, after going to all the trouble of thinking up the SCM_CREDS hack, making it work, and then patting myself on the back for being clever, I opened up my brand new copy of _UNIX Network Programming, 2nd Edition, Vol I_ and found that some fool at BSDi had come up with the idea first. :) NetBSD uses the BSD/OS approach rather than the FreeBSD approach. In theory, you could have both. I still say the per-message credential mechanism works better with RPC, but I'm just a crotchety old fart anyway. With regards to `the per-message credential mechanism works better with RPC': in fact, the way Solaris handles this (now?) is a per-message credential mechanism. Local RPC is implemented on top of doors (see UNPv2 chapter 15) rather than sockets. A doors procedure can use door_cred() to get client creditials each time it is invoked (i.e. per message). Switching gears back to the BSD/OS approach you mentioned, UNPv1 says, On a datagram socket, the credentials accompany every datagram. On a stream socket, the credentials are sent only once, the first time data is sent. So as long as one is using a SOCK_DGRAM socket, the BSD/OS-NetBSD approach should be analogous to what we have currently in FreeBSD? -- Jacques Vidrine / [EMAIL PROTECTED] / [EMAIL PROTECTED] / [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Optimizations (was: Why not another style thread? (was Re: cvs commit: src/lib/libc/gen getgrent.c))
On Tue, Dec 19, 2000 at 06:36:06PM -0600, Peter Seebach wrote: In message [EMAIL PROTECTED], Greg Lehey writes: In which processors is a function call anywhere near as cheap as a conditional local branch? Doesn't PPC have some cases where a leaf function is basically free? Maybe, but free() is not a leaf function. -- Jacques Vidrine / [EMAIL PROTECTED] / [EMAIL PROTECTED] / [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Why not another style thread? (was Re: cvs commit: src/lib/libc/gen getgrent.c)
On Tue, Dec 19, 2000 at 04:01:52PM -0800, David O'Brien wrote: On Mon, Dec 18, 2000 at 01:11:12PM -0600, Jacques A. Vidrine wrote: /* Case 1 */ /* Case 2 */ if (data) vs. free(data) free(data); Actually from an optimization standpoint, #1 can be worse (ie, harder on the processor). You've got a conditional jump there that is using branch prediction HW to track (which means there is some other conditional branch you're not, you're fetching both the taken and not take paths, etc... If the function call isn't expensive, #2 can be "faster". There's more overhead than just the function call itself. For example, our free() will do some locking check for recursion beforing calling another function that actually does the work. -- Jacques Vidrine / [EMAIL PROTECTED] / [EMAIL PROTECTED] / [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Why not another style thread? (was Re: cvs commit: src/lib/libc/gen getgrent.c)
On Sun, Dec 17, 2000 at 10:01:58PM -0700, Warner Losh wrote: In message [EMAIL PROTECTED] "Jacques A. Vidrine" writes: : I hate to give up a line for : : if (data) : free(data); : : but neither do I care for ``if (data) free(data);''. I guess if I : were writing several statements like that in a single file, I would : consider the macro route (e.g. xfree). No offense, but this strikes me as a premature, sub-micro optimization. None taken. It is however a simple and safe optimization, with no apparent downsides. It has the same attraction as using bit shifts instead of multiplication/division, or saving the value from a function call that will be needed again later, even if you know the function call is trivial. I doubt that you could measure any difference between if (foo) free(foo); and free(foo); in the real world. This is probably correct for most applications. Nevertheless, I tend to write it that way at times -- maybe because it seems so natural to me to ask `do I need to free this thing?' -- and that gets translated directly to code. -- Jacques Vidrine / [EMAIL PROTECTED] / [EMAIL PROTECTED] / [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Why not another style thread? (was Re: cvs commit: src/lib/libc/gen getgrent.c)
On Mon, Dec 18, 2000 at 11:40:43AM -0700, Warner Losh wrote: In message [EMAIL PROTECTED] "Jacques A. Vidrine" writes: : None taken. It is however a simple and safe optimization, with no : apparent downsides. It has the same attraction as using bit shifts : instead of multiplication/division, or saving the value from a function : call that will be needed again later, even if you know the function call : is trivial. You are trading a test against zero and code obfuscation against a function call. The function call is typically much less than even a multiplication or division would be. You get clearer, easier to read code that is smaller by allowing free to do its job and not trying to optimize things. Ever notice that you tend to send more email when you should be studying for a final? /* Case 1 */ /* Case 2 */ if (data) vs. free(data) free(data); I don't see that Case 1 obfuscates anything. In some cases I find it clearer: Case 1 implies that maybe no memory was allocated. Case 2 seems to imply that memory was indeed allocated. I guess I tend to think 'This needs to be freed, let free deal with the details so I won't have to be bothered with them.' Function abstraction is supposed to be about hiding details that don't matter. And in my opinion, this is one of those details. I think it depends on the context. I've also seen code written where this sort of thing was taken to an obscene degree where you'd have 10-30 layers all making the same validity tests to ensure the data was really really good when it was impossible to get down more than a layer or two and have it be bad. Before you say that more tests are good, I cleaned up this mess and was able to reduce 5 overlay regions (yes, 5!) on a pdp-11 fortran monster due to systematically eliminating them (well, I ifdef'd them out (we wrote a fortran preprocessor, but that's another story)). The code went from something like 500k to 225k by removing the redundant tests through all the layers. I know this is an extreme example, but it does go to show that sometimes these tests can be rather signficicant. I agree with what you are saying, and yes, it is an extreme example. I guess I was focused on the particular case of free(). I happy with the opinions I've received. Based on them, I seem to be in the minority of preferring `if (data) free(data);' in some cases. OTOH, our code base speaks differently than the email I've received -- `if (data) free(data);' seems to be used quite alot. I will probably continue to use it the way I have before -- to make it clear that there may or may not be memory to free at this point. Cheers, -- Jacques Vidrine / [EMAIL PROTECTED] / [EMAIL PROTECTED] / [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: kernel type
On Sun, Dec 17, 2000 at 12:14:07AM +, Tony Finch wrote: Patryk Zadarnowski [EMAIL PROTECTED] wrote: Now that I think of it, there aren't many commercial microkernel systems out there with the possible exception of QNX and lots of little embedded toys. Mac OS X is based on Mach. Yes, but Mac OS X isn't Mach and it isn't a microkernel [*] -- it's a hybrid. -- Jacques Vidrine / [EMAIL PROTECTED] / [EMAIL PROTECTED] / [EMAIL PROTECTED] [*] For most, but perhaps not all, values of microkernel To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: kernel type
On Sun, Dec 17, 2000 at 12:27:55PM -0500, Robert Watson wrote: -- I've been seriously considering looking at adapting FreeBSD to use netinfo also, given that it provides a time-tested model for configuration management (local and distributed). It probably needs some cleaning up in the security sense, and possibly rewriting, but it's a strong starting point, and liberally licensed. Most of netinfo will be supported via nsswitch and PADL.COM's nss-netinfo for FreeBSD 5.0. -- Jacques Vidrine / [EMAIL PROTECTED] / [EMAIL PROTECTED] / [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: kernel type
On Sun, Dec 17, 2000 at 02:02:56PM -0500, Robert Watson wrote: That's great news -- I assume however that this is limited to the account directory service functionality, as opposed to the more general configuration parameters (login.conf equivs, etc)? That's correct, at least for the near term. However, over time I expect more C library functions will be supported (by being rewritten to use nsdispatch(3)). -- Jacques Vidrine / [EMAIL PROTECTED] / [EMAIL PROTECTED] / [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Why not another style thread? (was Re: cvs commit: src/lib/libc/gen getgrent.c)
[This typo came from NetBSD, so in this particular source I have no intention of changing the style.] What do folks think about 1)if (data) free(data); versus 2)free(data); versus 3)#define xfree(x) if ((x) != NULL) free(x); xfree(data); -- Jacques Vidrine / [EMAIL PROTECTED] / [EMAIL PROTECTED] / [EMAIL PROTECTED] On Sun, Dec 17, 2000 at 01:10:41PM -0800, Jacques Vidrine wrote: nectar 2000/12/17 13:10:41 PST Modified files: lib/libc/gen getgrent.c Log: Fix mostly harmless typo: if (data); free(data); Discovered by: emacs cc-mode Revision ChangesPath 1.19 +2 -2 src/lib/libc/gen/getgrent.c To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Why not another style thread? (was Re: cvs commit: src/lib/libc/gen getgrent.c)
On Sun, Dec 17, 2000 at 03:17:35PM -0600, Chris Costello wrote:
2. The C standard dictates that free() does nothing when it
gets a NULL argument.
Well, it dictates that free(NULL) is safe -- it doesn't dictate that
it ``does nothing''. Which brings me to my next comment:
The other two are just extra clutter.
I suspect that the programmer writing
if (data)
free(data);
is motivated by the wish to avoid the function call overhead if you
already know darn well that there is nothing to free. In the
multithreaded case, there is probably some locking going on, too.
I don't blame authors of storage allocation code if they do not write
free like this:
void
free(void *p)
{
if (p == NULL)
return;
.
.
.
It would be silly to optimize for freeing NULL pointers.
--
Jacques Vidrine / [EMAIL PROTECTED] / [EMAIL PROTECTED] / [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: Why not another style thread? (was Re: cvs commit: src/lib/libc/gen getgrent.c)
On Sun, Dec 17, 2000 at 03:36:56PM -0600, Chris Costello wrote:
On Sunday, December 17, 2000, Jacques A. Vidrine wrote:
It would be silly to optimize for freeing NULL pointers.
You mean as seen in:
[snip ifree(), which checks for a NULL pointer, first thing]
called by free():
void
free(void *ptr)
{
THREAD_LOCK();
malloc_func = " in free():";
if (malloc_active++) {
wrtwarning("recursive call.\n");
malloc_active--;
return;
} else {
ifree(ptr);
.
.
.
That's how it's worked since before FreeBSD came into being.
It wasn't implemented the same, but it behaved the same.
I may have missed your point ... or maybe you are just agreeing with
what I wrote. For this particular implementation of free, you get the
following for `free(foo)' when foo == NULL:
function call and stack overhead for free()
lock something if we are threaded
pointer assignment
increment
compare and branch
function call and stack overhead for ifree()
compare and branch
unwind ifree()
More stuff if HAVE_UTRACE
decrement
unlock something
unwind free()
Compare to `if (foo) free(foo);'
compare and branch
i.e. FreeBSD's free() is not optimized for freeing NULL pointers. Not
that I think it should be -- as I said, that would be silly.
--
Jacques Vidrine / [EMAIL PROTECTED] / [EMAIL PROTECTED] / [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: Why not another style thread? (was Re: cvs commit: src/lib/libc/gen getgrent.c)
On Sun, Dec 17, 2000 at 04:04:42PM -0600, Chris Costello wrote: On Sunday, December 17, 2000, Jacques A. Vidrine wrote: I may have missed your point ... or maybe you are just agreeing with what I wrote. For this particular implementation of free, you get the following for `free(foo)' when foo == NULL: function call and stack overhead for free() lock something if we are threaded pointer assignment increment compare and branch function call and stack overhead for ifree() compare and branch unwind ifree() More stuff if HAVE_UTRACE decrement unlock something unwind free() FreeBSD's free() is not optimized for freeing NULL pointers. Not that I think it should be -- as I said, that would be silly. The code I pasted _was_ FreeBSD's code, Yes, I know. and it does optimize for freeing NULL pointers. How so? Many instructions that are unnecessary are executed when you call free with a NULL pointer (read what I wrote above). To optimize for this case would be to check whether or not the pointer was NULL before doing anything else. This is kinda silly, who the hell started this thread? :-) You can still check for the pointer if you wish, before you call free(). Of course. And it seems a prudent thing to do if NULL pointers are not uncommon in the code path. I hate to give up a line for if (data) free(data); but neither do I care for ``if (data) free(data);''. I guess if I were writing several statements like that in a single file, I would consider the macro route (e.g. xfree). -- Jacques Vidrine / [EMAIL PROTECTED] / [EMAIL PROTECTED] / [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: PAM issues..
On Thu, Dec 07, 2000 at 12:06:46AM +, Chris wrote: Hi, I have been writing a PAM module to do Kerberos 5 and AFS stuff, and have run across a couple of problems. Have you looked at ports/security/pam_krb5, by the way? This does Kerberos 5, but not AFS. The next is pam_setcred(). I've noticed that this is not actually called from login/etc, so it doesn't do much good. Is this intentional? Not that it matters much, for anything other than compatibility with other modules. Patching login et. al. to call pam_setcred is trivial. The only reason I haven't done so yet is because pam_setcred is all but useless. :-) I'm enclosing a previous message that I sent to the FreeBSD PAM maintainer (ok well it went to jdp first and then later to markm) to explain more fully. None of us have had time to address it yet, and this appears to be a bug in Linux-PAM (which is the implementation we use). Cheers, -- Jacques Vidrine / [EMAIL PROTECTED] / [EMAIL PROTECTED] / [EMAIL PROTECTED] Date: Mon, 6 Nov 2000 12:51:46 -0600 From: "Jacques A. Vidrine" [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: pam_setcred in login.c Hi John, You look like the PAM maintainer. Can I commit the following to src/usr.bin/login.c (actually, the below patch is for -STABLE but I mean to commit the equivalent to -CURRENT)? --- login.c.origFri Nov 3 21:12:40 2000 +++ login.c Mon Nov 6 12:00:46 2000 @@ -714,6 +714,9 @@ } else syslog(LOG_ERR, "Couldn't get PAM_USER: %s", pam_strerror(pamh, e)); + if ((e = pam_setcred(pamh, PAM_ESTABLISH_CRED)) != PAM_SUCCESS) + syslog(LOG_ERR, "Couldn't establish credentials: %s", + pam_strerror(pamh, e)); rval = 0; break; By the way, is it just me, or is pam_setcred broken? For example, with the following config file: login auth sufficient pam_skey.so login auth sufficient pam_krb5.so login auth required pam_unix.so Regardless of whether you authenticate with `skey', `krb5', or `unix', pam_sm_setcred is called in pam_skey.so, i.e. the search starts over. By my reading of the Solaris man page, pam_sm_setcred should be called in the module that successfully authenticated the user. At any rate this seems infinitely more useful. Excerpt from Solaris 2.6 pam(3): If the user has been successfully authenticated, the application calls pam_setcred() to set any user credentials associated with the authentication service. [...] For example, during the call to pam_authenticate(), service modules may store data in the handle that is intended for use by pam_setcred(). Just looking for a sanity check... Thanks! -- Jacques Vidrine / [EMAIL PROTECTED] / [EMAIL PROTECTED] / [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: res_ functions thread safe?
On Tue, Nov 21, 2000 at 01:31:06PM +0600, Max Khon wrote: if I understand correctly nsswitch patches implement getxxx_r functions as well Yes, but they have to live `on top of' the existing resolver. :-( -- Jacques Vidrine / [EMAIL PROTECTED] / [EMAIL PROTECTED] / [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Modifying msgrcv() and msgsnd()
On Thu, Nov 09, 2000 at 04:38:35PM +0100, Bjorn Tornqvist wrote:
I'm going to add 2 functioncalls to the kernel; msgrcv_t() msgsnd_t()
("t" as in timeout) where the user will be able to specify a maximum
amount of time they are prepared to wait for a message to be sent or
become available.
I just wonder if the rest of the freebsd community is interested in
these kinds of additions to the kernel? I'm pretty certain there is
alot more people out there who'd like this functionality. Should I
bother posting them to the list?
As a sidenote: The main reason I need this is since I can't use
longjmp()/setjmp() with alarm() between pthread contexts; with FreeBSD
5.0 this fix probably won't be necessary (but still nice to have
though).
And besides, I'd get paid to contribute to the project! =)
I think this might be better handled by a kevent filter for message
queues, if you are going to hack something in the kernel for your
application. At least then it might find some general use.
--
Jacques Vidrine / [EMAIL PROTECTED] / [EMAIL PROTECTED] / [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
symbols seek home
In what header file could GETGR_R_SIZE_MAX and GETPW_R_SIZE_MAX live? These are defines that can be used to specify the sizes of the buffers needed for getpw*_r/getgr*_r. I'd like to put them in unistd.h, and add _SC_GETGR_R_SIZE_MAX/ _SC_GETPW_R_SIZE_MAX as well (for use with sysconf), but I thought I'd ask around first. -- Jacques Vidrine / [EMAIL PROTECTED] / [EMAIL PROTECTED] / [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
call for testers: nsswitch + dynamic linking
[Please follow-up to only one list] Hello, I need more testers for the following! nsswitch extends the C library so that arbitrary sources may be consulted by database routines such as getpwent, gethostbyname, and so on. This implementation was based on NetBSD's implementation. I have enhanced it to make the interfaces thread safe, and to provide support for dynamically loaded nsswitch modules. Patches for 4-STABLE and 5-CURRENT are at: http://www.nectar.com/freebsd/nsswitch. Also available there are patches for PADL.COM's nss_ldap so that it may be used with FreeBSD. Incidentally this also adds reentrant versions of common routines such as getpwnam_r. Note that routines that eventually call the resolver are only as thread safe as the resolver -- i.e. not really. Please contact me with any comments/bugs/patches. Cheers, -- Jacques Vidrine / [EMAIL PROTECTED] / [EMAIL PROTECTED] / [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: _THREAD_SAFE in libc
On Thu, Oct 05, 2000 at 04:22:56PM -0700, Alfred Perlstein wrote: * Jacques A. Vidrine [EMAIL PROTECTED] [001005 16:18] wrote: Is it ok to use pthread_rwlock* and other such primitives in code in src/lib/libc (when _THREAD_SAFE is defined, of course)? It sure looks like it. cd /usr/src/lib/libc/ ; grep pthread */* I didn't see all those pthread_mutex*s because I was looking for pthread_rwlock*s :-) Which leads me to wonder if I _want_ pthread_rwlock. The overhead might outweigh the benefits of finer-grained locking. Besides, there doesn't seem to be a good way of promoting a lock from read-write. -- Jacques Vidrine / [EMAIL PROTECTED] / [EMAIL PROTECTED] / [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
_THREAD_SAFE in libc
Is it ok to use pthread_rwlock* and other such primitives in code in src/lib/libc (when _THREAD_SAFE is defined, of course)? I ask because I don't see any other code doing this. Perhaps there is a private interface to use? Perhaps I'm barking up the wrong tree? Context: I want to make nsdispatch thread safe (inasmuch as possible-- e.g. I'm not tackling the resolver), so I need to protect its data structures. -- Jacques Vidrine / [EMAIL PROTECTED] / [EMAIL PROTECTED] / [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: c++ error
On Wed, Sep 13, 2000 at 11:02:28PM -0500, Jacques A. Vidrine wrote: Please see PR bin/13383 before doing anything like this. It addresses a similar situation. I'll comment more tomorrow after some sleep :-) I knew I needed some sleep. It ``addressess'' the exact same situation. In summary, gcc has a kluge to work around a bug in the C++ standard. It looks like you and Justin have both found edge cases where the gcc kluge loses. If you can come up with a reasonable test case that reproduces the problem, perhaps it can be PR'd to the GCC folks? As per the PR, I'm against #ifdef'ing structures like ip_opts for C++, since it is likely that a later C++ standard will be corrected. -- Jacques Vidrine / [EMAIL PROTECTED] / [EMAIL PROTECTED] / [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: c++ error
On Wed, Sep 13, 2000 at 05:36:05PM -0700, John Polstra wrote:
About the best fix I can think of (and it's not very good) is to
change netinet/in.h so the structure is declared like this:
struct ip_opts {
struct in_addr ip_dst; /* first hop, 0 w/o src rt */
#ifdef __cplusplus
charip_optbuf[40]; /* actually variable in size */
#else
charip_opts[40];/* actually variable in size */
#endif
};
This shouldn't break any C++ code, since it already wouldn't compile
anyway. :-)
Please see PR bin/13383 before doing anything like this. It addresses
a similar situation. I'll comment more tomorrow after some sleep :-)
--
Jacques Vidrine / [EMAIL PROTECTED] / [EMAIL PROTECTED] / [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: Anyone try the new dual-head G-400 drivers?
On Fri, Aug 25, 2000 at 11:52:18AM -0400, Tim Grzechowski wrote: We tried using the freebie stuff with Xfree86 4.0.1 but found it to be extreamly buggy... both on Linux and FreeBSD. Could you describe `extremely buggy'? Did you open any problem reports with the XFree86 guys? I have been using the Matrox G400 Dual-Head AGP card with XFree86 4.0.1 + Matrox's Linux driver since August 18 with zero problems. Works perfectly. I was previously using a Matrox Millenium II AGP + Matrox Millenium II PCI since the XFree86 3.9 days. Like you, I will kill anyone who attempts to make off with one of my monitors :-) -- Jacques Vidrine / [EMAIL PROTECTED] / [EMAIL PROTECTED] / [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: Testers wanted: nsswitch
On Wed, Aug 23, 2000 at 02:08:59AM +0900, Hajimu UMEMOTO wrote: [snip] Your nsswith support in getaddrinfo.c is quite different from NetBSD's one. (maybe name6.c, too?) Why don't you simply bring the code from NetBSD? The origin of getadrinfo.c and name6.c is KAME, and basically these files are same between NetBSD and FreeBSD except some OS depend part such as reading host.conf. We should keep close these files to NetBSD as possible. I intended to inquire about this: I wasn't sure if there were many FreeBSDisms in the resolver, and because I have a healthy fear of breaking the resolver, I tried not to change its behavior significantly. Now that I understand the source of getadrinfo.c and name6.c, I will indeed sync them with NetBSD inasmuch as is possible. Thanks for bringing this up! -- Jacques Vidrine / [EMAIL PROTECTED] / [EMAIL PROTECTED] / [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
What exactly does this mean? (ld: size of symbol changed)
I hope someone might be able to clue me in. I'm having a hard time tracking this down. I've added some code to libc, and while building the world I get this misery in src/sbin/dhclient: cc -O -pipe -I/usr/src/sbin/dhclient/../../contrib/isc-dhcp/includes -I/usr/src/sbin/dhclient/../../contrib/isc-dhcp -DCLIENT_PATH='"PATH=/sbin:/bin:/usr/sbin:/usr/bin"'-static -o dhclient clparse.o dhclient.o alloc.o bpf.o conflex.o convert.o dispatch.o errwarn.o ethernet.o hash.o icmp.o inet.o inet_addr.o memory.o nit.o options.o packet.o parse.o print.o raw.o socket.o tables.o tree.o upf.o /usr/lib/libc.a(err.o): In function `warn': err.o(.text+0x1e0): multiple definition of `warn' errwarn.o(.text+0xd8): first defined here /usr/libexec/elf/ld: Warning: size of symbol `warn' changed from 141 to 30 in err.o *** Error code 1 I guess I just don't understand exactly what the linker is trying to tell me. BTW, this is ~ 4.1-RELEASE. Thanks, -- Jacques Vidrine / [EMAIL PROTECTED] / [EMAIL PROTECTED] / [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: What exactly does this mean? (ld: size of symbol changed)
On Thu, Aug 10, 2000 at 04:12:23PM -0400, James Housley wrote:
My guess is that you (or someone) have redefined the function warn().
Good guess, but no cigar :-)
warn is defined once in libc, and once in errwarn.c. This is OK
normally, but I've screwed up something in the build.
errwarn.c is dhclient. Are you compiling dhclient from
/usr/src/contrib/isc-dhcp instead of /usr/src/sbin/dhclient? The second
is the correct locaion.
src/sbin/dhclient as I mentioned in my first message.
Could `CFLAGS+= -I${.OBJDIR}' in src/lib/libc/net/Makefile.inc cause me
to lose in this fashion? If so, how else might I get to a generated file
(i.e. header output from yacc)?
Thanks,
--
Jacques Vidrine / [EMAIL PROTECTED] / [EMAIL PROTECTED] / [EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-hackers" in the body of the message
Re: XFree86 4.0 - What are people using for dual-head video?
On Fri, Jun 30, 2000 at 08:41:42AM -0400, Thomas Stromberg wrote: It's my understanding that there still isn't support for the dual-head cards from Matrox, unless you go with a commercial X server. If anyone could point me to a dual-head compatibility list, that'd help too. I use XFree86 4.0 (on 4-STABLE) with: pci0: Matrox MGA Millennium II 2164W graphics accelerator at 15.0 irq 9 pci1: Matrox MGA Millennium II 2164WA-B AG graphics accelerator at 0.0 irq 3 One is AGP, one is PCI. Not enough window managers understand multiple displays. Happily, WindowMaker does. -- Jacques Vidrine / [EMAIL PROTECTED] / [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
Re: need to borrow a clue re: rtld
On Tue, May 16, 2000 at 09:37:44AM -0700, John Polstra wrote: Which version of FreeBSD? 4.0-STABLE ~ May 8. If you have time, please rebuild "src/libexec/rtld-elf" with DEBUG_FLAGS=-DDEBUG. [logs for telnet and xchat sent off-list] I should have mentioned earlier that in the fail case, xchat operates until it tries to connect to a server (i.e. when you push the connect button), as opposed to failing during the initial loading of libraries. Thanks for helping with this! -- Jacques Vidrine / [EMAIL PROTECTED] / [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
need to borrow a clue re: rtld
Hi All, Messing about with Dante (the SOCKS5 replacement), I've encountered some difficulty with run-time linking that I don't understand. In brief: $ env LD_PRELOAD=libdsocks.so telnet # works $ env LD_PRELOAD=libdsocks.so xchat # undefined symbol '_gethostbyname' $ env LD_PRELOAD=libc.so:libdsocks.so xchat # works What I don't understand is: = Why is the run-time linker failing to find _gethostbyname in libc in the second case? Looking at a ktrace shows that the relative order of loading libdsocks.so and libc.so is the same for both telnet and xchat, but the latter `doesn't work'. I thought LD_BIND_NOW might be useful here, but it isn't. The same problem is encountered even if the application is linked (dynamically) with -ldsocks at build time (i.e. undefined symbol unless I supply LD_PRELOAD=libc.so). What might I look for in the build of libdsocks.so that would cause such? Thanks for any help! -- Jacques Vidrine / [EMAIL PROTECTED] / [EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with "unsubscribe freebsd-hackers" in the body of the message
