From owner-freebsd-arch Sun Apr 21 1:48:45 2002 Delivered-To: freebsd-arch@freebsd.org Received: from rwcrmhc54.attbi.com (rwcrmhc54.attbi.com [216.148.227.87]) by hub.freebsd.org (Postfix) with ESMTP id 3280037B419 for ; Sun, 21 Apr 2002 01:48:43 -0700 (PDT) Received: from gateway.posi.net ([12.236.90.177]) by rwcrmhc54.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020421084842.PATJ1102.rwcrmhc54.attbi.com@gateway.posi.net> for ; Sun, 21 Apr 2002 08:48:42 +0000 Received: from localhost (kbyanc@localhost) by gateway.posi.net (8.11.6/8.11.6) with ESMTP id g3L8mgE87411 for ; Sun, 21 Apr 2002 01:48:42 -0700 (PDT) (envelope-from kbyanc@posi.net) X-Authentication-Warning: gateway.posi.net: kbyanc owned process doing -bs Date: Sun, 21 Apr 2002 01:48:42 -0700 (PDT) From: Kelly Yancey To: arch@freebsd.org Subject: Overflowing sockaddr_dl's sdl_data buffer Message-ID: <20020421013332.F87395-100000@gateway.posi.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG While working on a product at work, I discovered that it is trivial to overflow the sdl_data buffer in sockaddr_dl structures. In our case, I enountered the bug by creating a vlan100 interface. The sdl_data buffer is populated with both the interface name and the parent interface's hardware address; in his case 7 characters for the interface name and 6 more for the parent's MAC address for a total of 13 characters (sdl_data is only defined for 12 characters). As a result, the sdl_rcf field is garbage (actually, the last octet of the MAC address). While, I worked around the problem in our product, I would prefer to see the bug fixed in FreeBSD proper. So, I would like to solicit discussion of the proper fix for this bug. Should sdl_data's length be extended (say 16 characters)? This would surely break binary compatibility and only postpones the issue (imagine an interface with a longer name). Should bound's checking be added to eliminate the (supposedly optional) interface name from the sdl_data buffer if there is not room? If so, how does one ensure all drivers (including 3rd party) perform the bounds-checking? Surely there are other options too. In any event, the comment in sys/net/if_dl.h for the sdl_data field needs updating because since the source routing information was added following the sdl_data field it is impossible for the sdl_data field to be larger than that defined by the structure definition. Thanks, Kelly kbyanc@{posi.net,FreeBSD.org} To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Apr 21 5:51:37 2002 Delivered-To: freebsd-arch@freebsd.org Received: from iguana.icir.org (iguana.icir.org [192.150.187.36]) by hub.freebsd.org (Postfix) with ESMTP id B7E7937B417 for ; Sun, 21 Apr 2002 05:51:32 -0700 (PDT) Received: (from rizzo@localhost) by iguana.icir.org (8.11.6/8.11.3) id g3LCpWp90545; Sun, 21 Apr 2002 05:51:32 -0700 (PDT) (envelope-from rizzo) Date: Sun, 21 Apr 2002 05:51:32 -0700 From: Luigi Rizzo To: arch@freebsd.org Subject: Where do we put dependencies between kernel config options ? Message-ID: <20020421055132.B90381@iguana.icir.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.23i Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG As the subject says... It seems that we do not have a place to put dependencies among kernel config options and devices. Is there any plan to implement a mechanism to record dependencies, and then either import the necessary entries, or report the missing ones without waiting for a kernel failure to link (or, in case of modules, fail to load) ? I think there is something like that, but not quite, for modules. cheers luigi To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sun Apr 21 11:26:57 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mail-blue.research.att.com (mail-blue.research.att.com [135.207.30.102]) by hub.freebsd.org (Postfix) with ESMTP id A968437B404 for ; Sun, 21 Apr 2002 11:26:55 -0700 (PDT) Received: from alliance.research.att.com (alliance.research.att.com [135.207.26.26]) by mail-blue.research.att.com (Postfix) with ESMTP id C39A14CE8E; Sun, 21 Apr 2002 14:27:26 -0400 (EDT) Received: from windsor.research.att.com (windsor.research.att.com [135.207.26.46]) by alliance.research.att.com (8.8.7/8.8.7) with ESMTP id OAA09418; Sun, 21 Apr 2002 14:26:52 -0400 (EDT) From: Bill Fenner Received: (from fenner@localhost) by windsor.research.att.com (8.8.8+Sun/8.8.5) id LAA05288; Sun, 21 Apr 2002 11:26:51 -0700 (PDT) Message-Id: <200204211826.LAA05288@windsor.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: kbyanc@posi.net Subject: Re: Overflowing sockaddr_dl's sdl_data buffer Cc: arch@FreeBSD.ORG Date: Sun, 21 Apr 2002 11:26:51 -0700 Versions: dmail (solaris) 2.4/makemail 2.9b Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG I think that sdl_data should go back to being a variable-length buffer, and the source routing stuff should be reimplemented somewhere else (perhaps at the end of the variable-length buffer). What uses the source-routing fields? Bill To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Apr 22 13:57:16 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mail-blue.research.att.com (mail-blue.research.att.com [135.207.30.102]) by hub.freebsd.org (Postfix) with ESMTP id CCEE337B84D for ; Mon, 22 Apr 2002 13:56:30 -0700 (PDT) Received: from alliance.research.att.com (alliance.research.att.com [135.207.26.26]) by mail-blue.research.att.com (Postfix) with ESMTP id 621824CEA7; Mon, 22 Apr 2002 12:10:07 -0400 (EDT) Received: from windsor.research.att.com (windsor.research.att.com [135.207.26.46]) by alliance.research.att.com (8.8.7/8.8.7) with ESMTP id MAA16012; Mon, 22 Apr 2002 12:10:05 -0400 (EDT) From: Bill Fenner Received: (from fenner@localhost) by windsor.research.att.com (8.8.8+Sun/8.8.5) id JAA16254; Mon, 22 Apr 2002 09:10:04 -0700 (PDT) Message-Id: <200204221610.JAA16254@windsor.research.att.com> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII To: tlambert2@mindspring.com Subject: Re: Overflowing sockaddr_dl's sdl_data buffer Cc: kbyanc@posi.net, arch@FreeBSD.ORG References: <200204211826.LAA05288@windsor.research.att.com> <3CC3CAC2.12D2ED18@mindspring.com> Date: Mon, 22 Apr 2002 09:10:04 -0700 Versions: dmail (solaris) 2.4/makemail 2.9b Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG This is link-layer source routing; AFAIK only possible on token ring LANs. Bill To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Apr 22 16:25: 7 2002 Delivered-To: freebsd-arch@freebsd.org Received: from deathrow.mail.pas.earthlink.net (deathrow.mail.pas.earthlink.net [207.217.120.19]) by hub.freebsd.org (Postfix) with ESMTP id 60FE737C50E for ; Mon, 22 Apr 2002 16:21:51 -0700 (PDT) Received: from hawk.mail.pas.earthlink.net ([207.217.120.22]) by deathrow.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 16zZGv-0006Y2-00 for arch@freebsd.org; Mon, 22 Apr 2002 01:34:05 -0700 Received: from pool0030.cvx21-bradley.dialup.earthlink.net ([209.179.192.30] helo=mindspring.com) by hawk.mail.pas.earthlink.net with esmtp (Exim 3.33 #2) id 16zZGP-0002yw-00; Mon, 22 Apr 2002 01:33:34 -0700 Message-ID: <3CC3CAC2.12D2ED18@mindspring.com> Date: Mon, 22 Apr 2002 01:33:06 -0700 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Bill Fenner Cc: kbyanc@posi.net, arch@FreeBSD.ORG Subject: Re: Overflowing sockaddr_dl's sdl_data buffer References: <200204211826.LAA05288@windsor.research.att.com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Bill Fenner wrote: > I think that sdl_data should go back to being a variable-length buffer, > and the source routing stuff should be reimplemented somewhere else > (perhaps at the end of the variable-length buffer). > > What uses the source-routing fields? I know of several "script kiddie" tools which use it. Most sane people turn it off on their routers, so mostly the tools don't work. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Mon Apr 22 16:28: 9 2002 Delivered-To: freebsd-arch@freebsd.org Received: from deathrow.mail.pas.earthlink.net (deathrow.mail.pas.earthlink.net [207.217.120.19]) by hub.freebsd.org (Postfix) with ESMTP id 17D6237B6AF for ; Mon, 22 Apr 2002 16:21:40 -0700 (PDT) Received: from pintail.mail.pas.earthlink.net ([207.217.120.122]) by deathrow.mail.pas.earthlink.net with esmtp (Exim 3.33 #1) id 16zYtJ-0007BN-00 for arch@freebsd.org; Mon, 22 Apr 2002 01:09:41 -0700 Received: from pool0030.cvx21-bradley.dialup.earthlink.net ([209.179.192.30] helo=mindspring.com) by pintail.mail.pas.earthlink.net with esmtp (Exim 3.33 #2) id 16zYoJ-0005wK-00; Mon, 22 Apr 2002 01:04:31 -0700 Message-ID: <3CC3C3F3.1D9EEACB@mindspring.com> Date: Mon, 22 Apr 2002 01:04:03 -0700 From: Terry Lambert X-Mailer: Mozilla 4.7 [en]C-CCK-MCD {Sony} (Win98; U) X-Accept-Language: en MIME-Version: 1.0 To: Luigi Rizzo Cc: arch@freebsd.org Subject: Re: Where do we put dependencies between kernel config options ? References: <20020421055132.B90381@iguana.icir.org> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Luigi Rizzo wrote: > As the subject says... It seems that we do not have a place to > put dependencies among kernel config options and devices. > Is there any plan to implement a mechanism to record > dependencies, and then either import the necessary entries, or > report the missing ones without waiting for a kernel failure to > link (or, in case of modules, fail to load) ? > > I think there is something like that, but not quite, for modules. Module dependencies on named modules aren't strictly recorded, because auto-loading isn't supported; if you want to hack up auto-loading, then it's probably reasonable to add a dependency, other than failing due to undefined symbols. For ordinary configuration option interdependencies... I think they should be administratively prohibited. If you don't let them happen, then you don't have to deal with the fallout. Kind of like dealing with nuclear accidents. -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Apr 23 0:23:27 2002 Delivered-To: freebsd-arch@freebsd.org Received: from kayak.xcllnt.net (209-128-86-226.bayarea.net [209.128.86.226]) by hub.freebsd.org (Postfix) with ESMTP id 639F137B4DF for ; Tue, 23 Apr 2002 00:23:02 -0700 (PDT) Received: from athlon.pn.xcllnt.net (athlon.pn.xcllnt.net [192.168.4.3]) by kayak.xcllnt.net (8.11.6/8.11.4) with ESMTP id g3N7MjJ65146 for ; Tue, 23 Apr 2002 00:22:45 -0700 (PDT) (envelope-from marcel@kayak.pn.xcllnt.net) Received: from athlon.pn.xcllnt.net (localhost [127.0.0.1]) by athlon.pn.xcllnt.net (8.12.3/8.12.2) with ESMTP id g3N7MiCf072416 for ; Tue, 23 Apr 2002 00:22:44 -0700 (PDT) (envelope-from marcel@athlon.pn.xcllnt.net) Received: (from marcel@localhost) by athlon.pn.xcllnt.net (8.12.3/8.12.3/Submit) id g3N7MiVo072395 for arch@FreeBSD.org; Tue, 23 Apr 2002 00:22:44 -0700 (PDT) Date: Tue, 23 Apr 2002 00:22:44 -0700 From: Marcel Moolenaar To: arch@FreeBSD.org Subject: RTLD fix: part 1: kernel modules Message-ID: <20020423072244.GA40461@athlon.pn.xcllnt.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.3.27i Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Gang, The attached diff is primarily created to resolve a RTLD problem on ia64, but should prevent other architectures from the same and also (potentially) improve dynamic linking performance. The bottom line is this: On ia64, local symbols are not added to the hash table. My guess is that the rationale is that if the symbol exists only for relocation purposes, then you don't need to do a lookup because the relocation has the index of the symbol. Provided that linkers will not do lookups when not needed, this is safe. Unfortunately, we always do lookups (hash based). As such, we got unresolved symbols even though the symbol was in the symbol table; just not in the hash table. The attached diff changes the way we relocate for ELF. We don't pass the symbol name to elf_reloc anymore, because the relocation contains the index of the symbols. A new support function is created that does the lookup given the symbol index. For local symbols this is trivial. For global symbols we can avoid lookups in the future by being more smart. The second part is a similar change to ld-elf.so. I haven't looked at that yet. Compiles for alpha, i386 and ia64 Tested on ia64 Please review, -- Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Apr 23 0:25:22 2002 Delivered-To: freebsd-arch@freebsd.org Received: from kayak.xcllnt.net (209-128-86-226.bayarea.net [209.128.86.226]) by hub.freebsd.org (Postfix) with ESMTP id 53E6F37B41A for ; Tue, 23 Apr 2002 00:25:19 -0700 (PDT) Received: from athlon.pn.xcllnt.net (athlon.pn.xcllnt.net [192.168.4.3]) by kayak.xcllnt.net (8.11.6/8.11.4) with ESMTP id g3N7PIJ65157 for ; Tue, 23 Apr 2002 00:25:18 -0700 (PDT) (envelope-from marcel@kayak.pn.xcllnt.net) Received: from athlon.pn.xcllnt.net (localhost [127.0.0.1]) by athlon.pn.xcllnt.net (8.12.3/8.12.2) with ESMTP id g3N7PICf074918 for ; Tue, 23 Apr 2002 00:25:18 -0700 (PDT) (envelope-from marcel@athlon.pn.xcllnt.net) Received: (from marcel@localhost) by athlon.pn.xcllnt.net (8.12.3/8.12.3/Submit) id g3N7PIBt074917 for arch@FreeBSD.ORG; Tue, 23 Apr 2002 00:25:18 -0700 (PDT) Date: Tue, 23 Apr 2002 00:25:18 -0700 From: Marcel Moolenaar To: arch@FreeBSD.ORG Subject: Re: RTLD fix: part 1: kernel modules Message-ID: <20020423072518.GB40461@athlon.pn.xcllnt.net> References: <20020423072244.GA40461@athlon.pn.xcllnt.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020423072244.GA40461@athlon.pn.xcllnt.net> User-Agent: Mutt/1.3.27i Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Tue, Apr 23, 2002 at 12:22:44AM -0700, Marcel Moolenaar wrote: > Gang, > > The attached diff is primarily created to resolve a RTLD problem > on ia64, but should prevent other architectures from the same and > also (potentially) improve dynamic linking performance. Duh... The diff can be found here: http://www.xcllnt.net/~marcel/kld.diff -- Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Tue Apr 23 7:46:47 2002 Delivered-To: freebsd-arch@freebsd.org Received: from castor.email.si (mail.email.si [193.77.122.6]) by hub.freebsd.org (Postfix) with ESMTP id 3FBC537B41B for ; Tue, 23 Apr 2002 07:46:44 -0700 (PDT) Received: from primoz (BSN-250-59-137.dsl.siol.net [213.250.59.137]) by castor.email.si (8.11.1/8.11.1) with ESMTP id g3NEkdu09948 for ; Tue, 23 Apr 2002 16:46:39 +0200 Message-ID: <200204231646390173.000F35FF@mail.email.si> X-Mailer: Calypso Version 3.30.00.00 (4) Date: Tue, 23 Apr 2002 16:46:39 +0200 From: "LUDWIG" To: FREEBSD-ARCH@FREEBSD.ORG Subject: Re:Pocitnice Mime-Version: 1.0 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: quoted-printable Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Si =9Eelite oddiha ?? ....se odpravljate na dopust pa ne veste kam ??..... HRVA=8AKA ? =C8RNA GORA? Vabimo vas, da nas obi=9A=E8ete na na=9Aih spletnih straneh in si ogledate na=9Ao pestro ponudbo ali pa nas obi=9A=E8ete v na=9Ai poslovalnici v= =8Aentjan=9Eu ali v Ljubljani. Ponujamo vam najugodnej=9Ae potovalne aran=9Emaje na hrva=9Ako in= =E8rnogorsko obalo. 7 dnevni polpenzion =9Ee od 18.00 SIT. Mo=9Enost najema apartmaja. Mo=9Eno= pla=E8ilo na ve=E8 obrokov. Trenutno akcija za prvomajska letovanja...... Pa kaj bi na=9Atevali, prepri=E8ajte se sami. Neverjetno nizke cene= po=E8itnic. Z veseljem vas pri=E8akujemo na naslovu: http://www.agencijasonja-sp.si ali na tel.=9At 01/426 72 52 Lep pozdrav To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Apr 24 12:23:37 2002 Delivered-To: freebsd-arch@freebsd.org Received: from 12-234-22-238.client.attbi.com (12-234-90-219.client.attbi.com [12.234.90.219]) by hub.freebsd.org (Postfix) with ESMTP id AAF5D37B405; Wed, 24 Apr 2002 12:23:29 -0700 (PDT) Received: from Master.gorean.org (master.gorean.org [10.0.0.2]) by 12-234-22-238.client.attbi.com (8.12.2/8.12.2) with ESMTP id g3OJMaHt083408; Wed, 24 Apr 2002 12:22:36 -0700 (PDT) (envelope-from DougB@FreeBSD.org) Received: from Master.gorean.org (zoot [127.0.0.1]) by Master.gorean.org (8.12.2/8.12.2) with ESMTP id g3OJMcLr067831; Wed, 24 Apr 2002 12:22:38 -0700 (PDT) (envelope-from DougB@FreeBSD.org) Received: from localhost (doug@localhost) by Master.gorean.org (8.12.2/8.12.2/Submit) with ESMTP id g3OJMbfk067828; Wed, 24 Apr 2002 12:22:37 -0700 (PDT) X-Authentication-Warning: Master.gorean.org: doug owned process doing -bs Date: Wed, 24 Apr 2002 12:22:37 -0700 (PDT) From: Doug Barton X-X-Sender: doug@master.gorean.org Reply-To: freebsd-arch@FreeBSD.org To: Mike Silbersack Cc: Paul Traina , Peter Wemm , , Subject: Re: IP port ephemeral range In-Reply-To: <20020423233952.V1720-100000@patrocles.silby.com> Message-ID: <20020424120734.O67562-100000@master.gorean.org> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG [ Re-directing to -arch to get a wider audience involved. ] On Tue, 23 Apr 2002, Mike Silbersack wrote: > > On Tue, 23 Apr 2002, Doug Barton wrote: > > > Mike, > > > > I appreciate your eagerness to get this change out to our > > userbase, but I really think it's too big a change for releng_4. I > > personallly would really like to see the whole thing backed out in that > > branch, and give the code time to gel in -current. What do you think? > > I think you stated it best a few days ago, Doug: > > "I'm really beginning to sympathize with obrien's perspective that > doing anything useful around here isn't worth having to put up with the > kibitzing." Funny you should quote that... while I still believe that it's true, I eventually realized that _some_ of the kibitzing was valid, and that some of the changes I merged into -stable were too much, so I backed them out. > I'm happy to work with Paul. He has stated a valid complaint, and > has helped to determine what an acceptable solution would be. However, I > can't hold up MFCing changes forever just because people believe that > releng_4 should never change. I am not suggesting that, nor do I believe it. In fact, quite the opposite, I'm a vigorous campaigner for mfc's, especially during this loooong development cycle for 5.0. However, I am concerned that the change you've pushed through is too much of a POLA violation, if it's even a good idea. This change hasn't been put in a release yet, so it's not too late to back it out of releng_4 with minimal disruption to the users. > The idea of just leaving such a change in -current for comment isn't > working. The change which started this debate was commited to current > over a month ago. Aside from Peter, I heard very little comment before > the change was MFC'd. I've already apologized once for missing this discussion. I can't imagine I'm the only one who did. > We have a month-long code freeze coming up, that should be more than > enough time for the changes to get tested. Given that this is still a work in progress, I don't think one month is enough. We are relying heavily on the 4.x branch to be something users can cling to while we finish the 5.0 development. I think that this is the wrong time for a change like this, even if you do get the bugs worked out of -current. -- "We have known freedom's price. We have shown freedom's power. And in this great conflict, ... we will see freedom's victory." - George W. Bush, President of the United States State of the Union, January 28, 2002 Do YOU Yahoo!? To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Apr 24 18:56:23 2002 Delivered-To: freebsd-arch@freebsd.org Received: from numeri.campus.luth.se (numeri.campus.luth.se [130.240.197.103]) by hub.freebsd.org (Postfix) with ESMTP id 95CCE37B417; Wed, 24 Apr 2002 18:55:56 -0700 (PDT) Received: (from k@localhost) by numeri.campus.luth.se (8.11.6/8.11.6) id g3P1rrS74076; Thu, 25 Apr 2002 03:53:53 +0200 (CEST) (envelope-from k) Date: Thu, 25 Apr 2002 03:53:53 +0200 From: Johan Karlsson To: freebsd-arch@freebsd.org Subject: NOSUID and NOSUID_prog make knobs Message-ID: <20020425035353.A73613@numeri.campus.luth.se> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="fUYQa+Pmc3FrFX/N" Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG --fUYQa+Pmc3FrFX/N Content-Type: text/plain; charset=us-ascii Content-Disposition: inline [bcc -security since the discussion started there ] Hi all, recently a discussion about removing the setuid bit popup again http://docs.FreeBSD.org/cgi/getmsg.cgi?fetch=166393+0+current/freebsd-security Jason noted that it had been discussed before and also that introducing a make knob to disable installation of various programs with the setuid bit turned on had been proposed. I have started to implement this and would like to know what you think of the concept. Attached is an untested diff for some suid/sgid programs. Basicly it protects the BINMODE assignment in the Makefile with .if !defined(NOSUID) && !defined(NOSUID_prog) I have also made changes to make.conf.5 and examples/etc/make.conf to reflect the new knobs. Please have a look at the attached diff and let me know what you think. If there is interest and some commiter would consider to commit something along those lines I'm willing to make a diff for most of the suid/sgid programs we have in the tree. /Johan K -- Johan Karlsson mailto:k@numeri.campus.luth.se --fUYQa+Pmc3FrFX/N Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="NOSUID.diff" ? usr.sbin/sa ? usr.sbin/rpc.statd ? usr.sbin/rpc.umntall ? usr.sbin/rpc.yppasswdd ? usr.sbin/rpc.ypupdated ? usr.sbin/rpc.ypxfrd ? usr.sbin/rpcbind ? usr.sbin/rrenumd ? usr.sbin/rtadvd ? usr.sbin/rtprio ? usr.sbin/rtsold ? usr.sbin/rwhod ? usr.sbin/sendmail ? usr.sbin/setextattr ? usr.sbin/setkey ? usr.sbin/sgsc ? usr.sbin/sicontrol ? usr.sbin/sliplogin ? usr.sbin/slstat ? usr.sbin/spkrtest ? usr.sbin/spray ? usr.sbin/stallion Index: share/examples/etc/make.conf =================================================================== RCS file: /home/ncvs/src/share/examples/etc/make.conf,v retrieving revision 1.186 diff -u -r1.186 make.conf --- share/examples/etc/make.conf 2002/04/23 23:59:51 1.186 +++ share/examples/etc/make.conf 2002/04/25 01:29:12 @@ -88,6 +88,22 @@ # To enable installing ssh(1) with the setuid bit turned on #ENABLE_SUID_SSH= true # +# To avoid installing various parts with the setuid/setgid bit turned on +# +#NOSUID= true # no setuid bit for any of the below +#NOSUID_AT= true # no setuid bit for at +#NOSUID_CHPASS= true # no setuid bit for chpass +#NOSUID_K5SU= true # no setuid bit for k5su +#NOSUID_PING= true # no setuid bit for ping +#NOSUID_PING6= true # no setuid bit for ping6 +#NOSUID_PPP= true # no setuid bit for ppp +#NOSUID_RCP= true # no setuid bit for rcp +#NOSUID_SHUTDOWN= true # no setuid bit for shutdown +# +#NOSGID= true # no setgid bit for any of the below +#NOSGID_DM= true # no setgid bit for dm +#NOSGID_PS= true # no setgid bit for ps + # To avoid building various parts of the base system: #NO_CVS= true # do not build CVS #NO_CXX= true # do not build C++ and friends Index: share/man/man5/make.conf.5 =================================================================== RCS file: /home/ncvs/src/share/man/man5/make.conf.5,v retrieving revision 1.43 diff -u -r1.43 make.conf.5 --- share/man/man5/make.conf.5 2002/04/23 23:59:51 1.43 +++ share/man/man5/make.conf.5 2002/04/25 01:29:16 @@ -480,11 +480,39 @@ set to not build crypto code in .Pa secure subdir. +.It Va NOSGID +.Pq Vt bool +Set to disable the installation of all of the following +as sgid programs. +.It Va NOSGID_DM +.Pq Vt bool +Set to disable the installation of +.Xr dm 8 +as a sgid program. .It Va NOSHARE .Pq Vt bool Set to not build in the .Pa share subdir. +.It Va NOSGID +.Pq Vt bool +Set to disable the installation of all of the following +as suid programs. +.It Va NOSUID_AT +.Pq Vt bool +Set to disable the installation of +.Xr at 1 +as a suid program. +.It Va NOSUID_CHPASS +.Pq Vt bool +Set to disable the installation of +.Xr chpass 1 +as a suid program. +.It Va NOSUID_PPP +.Pq Vt bool +Set to disable the installation of +.Xr ppp 8 +as a suid program. .It Va NOUUCP .Pq Vt bool Set to not build @@ -496,11 +524,6 @@ .Xr perl 1 with thread support. -.It Va PPP_NOSUID -.Pq Vt bool -Set to disable the installation of -.Xr ppp 8 -as an suid root program. .It Va SENDMAIL_MC .Pq Vt str The default m4 configuration file to use at install time. Index: bin/ps/Makefile =================================================================== RCS file: /home/ncvs/src/bin/ps/Makefile,v retrieving revision 1.19 diff -u -r1.19 Makefile --- bin/ps/Makefile 2002/02/04 03:06:50 1.19 +++ bin/ps/Makefile 2002/04/25 01:29:36 @@ -14,7 +14,9 @@ WFORMAT=0 DPADD= ${LIBM} ${LIBKVM} LDADD= -lm -lkvm +.if !defined(NOSGID) && !defined(NOSGID_PS) #BINGRP= kmem #BINMODE=2555 +.endif .include Index: bin/rcp/Makefile =================================================================== RCS file: /home/ncvs/src/bin/rcp/Makefile,v retrieving revision 1.20 diff -u -r1.20 Makefile --- bin/rcp/Makefile 2002/04/18 07:01:34 1.20 +++ bin/rcp/Makefile 2002/04/25 01:29:36 @@ -21,8 +21,10 @@ .PATH: ${.CURDIR}/../../crypto/kerberosIV/appl/bsd .endif +.if !defined(NOSUID) && !defined(NOSUID_RCP) BINOWN= root BINMODE=4555 INSTALLFLAGS=-fschg +.endif .include Index: sbin/ping/Makefile =================================================================== RCS file: /home/ncvs/src/sbin/ping/Makefile,v retrieving revision 1.17 diff -u -r1.17 Makefile --- sbin/ping/Makefile 2001/12/04 02:19:55 1.17 +++ sbin/ping/Makefile 2002/04/25 01:29:48 @@ -3,8 +3,10 @@ PROG= ping MAN= ping.8 +.if !defined(NOSUID) && !defined(NOSUID_PING) BINOWN= root BINMODE=4555 +.endif .if ${MACHINE_ARCH} == "alpha" CFLAGS+=-fno-builtin # GCC's builtin memcpy doesn't do unaligned copies .endif Index: sbin/ping6/Makefile =================================================================== RCS file: /home/ncvs/src/sbin/ping6/Makefile,v retrieving revision 1.9 diff -u -r1.9 Makefile --- sbin/ping6/Makefile 2002/03/01 09:49:48 1.9 +++ sbin/ping6/Makefile 2002/04/25 01:29:48 @@ -6,8 +6,10 @@ CFLAGS+=-DINET6 -DIPSEC WARNS= 0 +.if !defined(NOSUID) && !defined(NOSUID_PING6) BINOWN= root BINMODE=4555 +.endif LDADD= -lipsec -lm -lmd DPADD= ${LIBIPSEC} ${LIBM} ${LIBMD} Index: usr.bin/at/Makefile =================================================================== RCS file: /home/ncvs/src/usr.bin/at/Makefile,v retrieving revision 1.15 diff -u -r1.15 Makefile --- usr.bin/at/Makefile 2002/02/08 22:31:35 1.15 +++ usr.bin/at/Makefile 2002/04/25 01:29:49 @@ -11,8 +11,10 @@ at.1 atq.1 \ at.1 atrm.1 +.if !defined(NUSUID) && !defined(NOSUID_AT) BINOWN= root BINMODE= 4555 +.endif CLEANFILES+= at.1 at.1: at.man Index: usr.bin/chpass/Makefile =================================================================== RCS file: /home/ncvs/src/usr.bin/chpass/Makefile,v retrieving revision 1.25 diff -u -r1.25 Makefile --- usr.bin/chpass/Makefile 2002/03/24 10:21:22 1.25 +++ usr.bin/chpass/Makefile 2002/04/25 01:29:51 @@ -6,8 +6,10 @@ table.c util.c ypxfr_misc.c ${GENSRCS} GENSRCS=yp.h yp_clnt.c yppasswd.h yppasswd_clnt.c yppasswd_private.h \ yppasswd_private_clnt.c yppasswd_private_xdr.c +.if !defined(NOSUID) && !defined(NOSUID_CHPASS) BINOWN= root BINMODE=4555 +.endif .PATH: ${.CURDIR}/../../usr.sbin/pwd_mkdb ${.CURDIR}/../../usr.sbin/vipw \ ${.CURDIR}/../../libexec/ypxfr \ ${.CURDIR}/../../usr.sbin/rpc.yppasswdd \ Index: usr.sbin/ppp/Makefile =================================================================== RCS file: /home/ncvs/src/usr.sbin/ppp/Makefile,v retrieving revision 1.94 diff -u -r1.94 Makefile --- usr.sbin/ppp/Makefile 2002/03/30 17:57:51 1.94 +++ usr.sbin/ppp/Makefile 2002/04/25 01:30:37 @@ -19,11 +19,11 @@ NOSUID= true .endif -.if defined(NOSUID) || defined(PPP_NOSUID) -BINMODE=554 -.else +.if !defined(NOSUID) && !defined(NOSUID_PPP) && !defined(PPP_NOSUID) BINMODE=4554 BINOWN= root +.else +BINMODE=554 .endif BINGRP= network M4FLAGS= --fUYQa+Pmc3FrFX/N-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Apr 24 19:22:14 2002 Delivered-To: freebsd-arch@freebsd.org Received: from dragon.nuxi.com (trang.nuxi.com [66.92.13.169]) by hub.freebsd.org (Postfix) with ESMTP id ABC8737B41B for ; Wed, 24 Apr 2002 19:22:02 -0700 (PDT) Received: from dragon.nuxi.com (obrien@localhost [127.0.0.1]) by dragon.nuxi.com (8.12.2/8.12.2) with ESMTP id g3P2IYYm047343; Wed, 24 Apr 2002 19:18:34 -0700 (PDT) (envelope-from obrien@dragon.nuxi.com) Received: (from obrien@localhost) by dragon.nuxi.com (8.12.3/8.12.2/Submit) id g3P2HHL2047163; Wed, 24 Apr 2002 19:17:17 -0700 (PDT) Date: Wed, 24 Apr 2002 19:17:17 -0700 From: "David O'Brien" To: Johan Karlsson Cc: freebsd-arch@freebsd.org Subject: Re: NOSUID and NOSUID_prog make knobs Message-ID: <20020424191717.A35128@dragon.nuxi.com> Reply-To: freebsd-arch@freebsd.org Mail-Followup-To: freebsd-arch@freebsd.org References: <20020425035353.A73613@numeri.campus.luth.se> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20020425035353.A73613@numeri.campus.luth.se>; from k@numeri.campus.luth.se on Thu, Apr 25, 2002 at 03:53:53AM +0200 X-Operating-System: FreeBSD 5.0-CURRENT Organization: The NUXI BSD group X-Pgp-Rsa-Fingerprint: B7 4D 3E E9 11 39 5F A3 90 76 5D 69 58 D9 98 7A X-Pgp-Rsa-Keyid: 1024/34F9F9D5 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Thu, Apr 25, 2002 at 03:53:53AM +0200, Johan Karlsson wrote: > Basicly it protects the BINMODE assignment in the Makefile with > .if !defined(NOSUID) && !defined(NOSUID_prog) ... > +# To avoid installing various parts with the setuid/setgid bit turned on > +# > +#NOSUID= true # no setuid bit for any of the below Either do them all, or none. This flag per binary does not scale, nor do I see any significant portion of our userbase utilizing the granularity. To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Apr 24 19:22:36 2002 Delivered-To: freebsd-arch@freebsd.org Received: from numeri.campus.luth.se (numeri.campus.luth.se [130.240.197.103]) by hub.freebsd.org (Postfix) with ESMTP id 5984237B41A; Wed, 24 Apr 2002 19:22:09 -0700 (PDT) Received: (from k@localhost) by numeri.campus.luth.se (8.11.6/8.11.6) id g3P2KS674570; Thu, 25 Apr 2002 04:20:28 +0200 (CEST) (envelope-from k) Date: Thu, 25 Apr 2002 04:20:28 +0200 From: Johan Karlsson To: Robert Watson Cc: freebsd-arch@freebsd.org Subject: Re: NOSUID and NOSUID_prog make knobs Message-ID: <20020425042028.B73613@numeri.campus.luth.se> References: <20020425035353.A73613@numeri.campus.luth.se> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: ; from rwatson@freebsd.org on Wed, Apr 24, 2002 at 10:06:18PM -0400 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Hi this patch was just to demostrate the concept it is by no means a compleate patch. I know that ps is not suid already, but since the BINMODE line only is commented out I made the change. /Johan K On Wed, Apr 24, 2002 at 22:06 (-0400) +0000, Robert Watson wrote: > Seems like a basically good idea. However, 'ps' should already not be > setgid in -CURRENT, and you appear to have missed some setgid monitoring > tools that do actually exist. The style weenies may have something to say > about variable naming, but this seems like a good thing to do. I have > some custom local hacks that do much the same, actually, but in a less > finished way. > > Robert N M Watson FreeBSD Core Team, TrustedBSD Project > robert@fledge.watson.org NAI Labs, Safeport Network Services > > On Thu, 25 Apr 2002, Johan Karlsson wrote: > > > [bcc -security since the discussion started there ] > > > > Hi all, > > > > recently a discussion about removing the setuid bit popup again > > http://docs.FreeBSD.org/cgi/getmsg.cgi?fetch=166393+0+current/freebsd-security > > > > Jason noted that it had been discussed before and also that > > introducing a make knob to disable installation of > > various programs with the setuid bit turned on had been proposed. > > > > I have started to implement this and would like to know > > what you think of the concept. > > > > Attached is an untested diff for some suid/sgid programs. > > > > Basicly it protects the BINMODE assignment in the Makefile with > > .if !defined(NOSUID) && !defined(NOSUID_prog) > > > > I have also made changes to make.conf.5 and examples/etc/make.conf > > to reflect the new knobs. > > > > Please have a look at the attached diff and let me know what you think. > > > > If there is interest and some commiter would consider to commit > > something along those lines I'm willing to make a diff for most > > of the suid/sgid programs we have in the tree. > > > > /Johan K > > -- > > Johan Karlsson mailto:k@numeri.campus.luth.se > > -- Johan Karlsson mailto:k@numeri.campus.luth.se To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Apr 24 19:52: 7 2002 Delivered-To: freebsd-arch@freebsd.org Received: from fledge.watson.org (fledge.watson.org [204.156.12.50]) by hub.freebsd.org (Postfix) with ESMTP id 68D2C37B417 for ; Wed, 24 Apr 2002 19:52:03 -0700 (PDT) Received: from fledge.watson.org (fledge.pr.watson.org [192.0.2.3]) by fledge.watson.org (8.11.6/8.11.6) with SMTP id g3P26Iw44803; Wed, 24 Apr 2002 22:06:18 -0400 (EDT) (envelope-from robert@fledge.watson.org) Date: Wed, 24 Apr 2002 22:06:18 -0400 (EDT) From: Robert Watson X-Sender: robert@fledge.watson.org To: Johan Karlsson Cc: freebsd-arch@FreeBSD.ORG Subject: Re: NOSUID and NOSUID_prog make knobs In-Reply-To: <20020425035353.A73613@numeri.campus.luth.se> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Seems like a basically good idea. However, 'ps' should already not be setgid in -CURRENT, and you appear to have missed some setgid monitoring tools that do actually exist. The style weenies may have something to say about variable naming, but this seems like a good thing to do. I have some custom local hacks that do much the same, actually, but in a less finished way. Robert N M Watson FreeBSD Core Team, TrustedBSD Project robert@fledge.watson.org NAI Labs, Safeport Network Services On Thu, 25 Apr 2002, Johan Karlsson wrote: > [bcc -security since the discussion started there ] > > Hi all, > > recently a discussion about removing the setuid bit popup again > http://docs.FreeBSD.org/cgi/getmsg.cgi?fetch=166393+0+current/freebsd-security > > Jason noted that it had been discussed before and also that > introducing a make knob to disable installation of > various programs with the setuid bit turned on had been proposed. > > I have started to implement this and would like to know > what you think of the concept. > > Attached is an untested diff for some suid/sgid programs. > > Basicly it protects the BINMODE assignment in the Makefile with > .if !defined(NOSUID) && !defined(NOSUID_prog) > > I have also made changes to make.conf.5 and examples/etc/make.conf > to reflect the new knobs. > > Please have a look at the attached diff and let me know what you think. > > If there is interest and some commiter would consider to commit > something along those lines I'm willing to make a diff for most > of the suid/sgid programs we have in the tree. > > /Johan K > -- > Johan Karlsson mailto:k@numeri.campus.luth.se > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Apr 24 20:18:46 2002 Delivered-To: freebsd-arch@freebsd.org Received: from numeri.campus.luth.se (numeri.campus.luth.se [130.240.197.103]) by hub.freebsd.org (Postfix) with ESMTP id 4E8BF37B41D for ; Wed, 24 Apr 2002 20:18:41 -0700 (PDT) Received: (from k@localhost) by numeri.campus.luth.se (8.11.6/8.11.6) id g3P3H5N75546 for freebsd-arch@freebsd.org; Thu, 25 Apr 2002 05:17:05 +0200 (CEST) (envelope-from k) Date: Thu, 25 Apr 2002 05:17:05 +0200 From: Johan Karlsson To: freebsd-arch@freebsd.org Subject: Re: NOSUID and NOSUID_prog make knobs Message-ID: <20020425051705.C73613@numeri.campus.luth.se> References: <20020425035353.A73613@numeri.campus.luth.se> <20020424191717.A35128@dragon.nuxi.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20020424191717.A35128@dragon.nuxi.com>; from dev-null@NUXI.com on Wed, Apr 24, 2002 at 07:17:17PM -0700 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In the discussion on -security I got the impression that the granularity is wanted. There are currently 29 suid and 14 sgid bits set it Makefile:s that would be effected by this. Some of them make sence to group togather e.g. lpr, ping, etc I think it just makes more sence to provide all of them (some grouped) than to only have 1 knob for all of them. /Johan K On Wed, Apr 24, 2002 at 19:17 (-0700) +0000, David O'Brien wrote: > On Thu, Apr 25, 2002 at 03:53:53AM +0200, Johan Karlsson wrote: > > Basicly it protects the BINMODE assignment in the Makefile with > > .if !defined(NOSUID) && !defined(NOSUID_prog) > ... > > +# To avoid installing various parts with the setuid/setgid bit turned on > > +# > > +#NOSUID= true # no setuid bit for any of the below > > Either do them all, or none. This flag per binary does not scale, nor do > I see any significant portion of our userbase utilizing the granularity. -- Johan Karlsson mailto:k@numeri.campus.luth.se To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Wed Apr 24 22:27:17 2002 Delivered-To: freebsd-arch@freebsd.org Received: from darius.concentric.net (darius.concentric.net [207.155.198.79]) by hub.freebsd.org (Postfix) with ESMTP id C97ED37B419 for ; Wed, 24 Apr 2002 22:27:13 -0700 (PDT) Received: from newman.concentric.net (newman.concentric.net [207.155.198.71]) by darius.concentric.net [Concentric SMTP Routing 1.0] id g3P5RCw08228 for ; Thu, 25 Apr 2002 01:27:12 -0400 (EDT) Received: from localhost ([64.3.150.191]) by newman.concentric.net (8.9.1a) id BAA05457; Thu, 25 Apr 2002 01:27:11 -0400 (EDT) Date: Wed, 24 Apr 2002 22:26:56 -0700 Mime-Version: 1.0 (Apple Message framework v481) Content-Type: text/plain; charset=US-ASCII; format=flowed Subject: Fwd: NOSUID and NOSUID_prog make knobs From: Jason DiCioccio To: freebsd-arch@freebsd.org Content-Transfer-Encoding: 7bit Message-Id: <0F346F4F-580D-11D6-8E6E-00039390808C@bluenugget.net> X-Mailer: Apple Mail (2.481) Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Granularity is wanted, at least by me and others I have spoken to. I don't know if it is best to clutter make.conf or if there is a better place, or a new place, that these knobs could be placed. However, if you're going to provide the flexibility I would think you should go all the way with it. Perhaps provide some canned sets, and/or the ability to make 'groups' of binaries in the configuration but there definitely has to be the ability to configure it to the level of individual binaries. IMHO :) Cheers, -JD- On Wednesday, April 24, 2002, at 08:17 PM, Johan Karlsson wrote: > In the discussion on -security I got the impression that the > granularity is wanted. > > There are currently 29 suid and 14 sgid bits set it Makefile:s > that would be effected by this. > Some of them make sence to group togather e.g. lpr, ping, etc > > I think it just makes more sence to provide all of them > (some grouped) than to only have 1 knob for all of them. > > /Johan K > > On Wed, Apr 24, 2002 at 19:17 (-0700) +0000, David O'Brien wrote: >> >> Either do them all, or none. This flag per binary does not scale, nor >> do >> I see any significant portion of our userbase utilizing the >> granularity. ---- Useless .sig To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Apr 25 0:32:17 2002 Delivered-To: freebsd-arch@freebsd.org Received: from rwcrmhc52.attbi.com (rwcrmhc52.attbi.com [216.148.227.88]) by hub.freebsd.org (Postfix) with ESMTP id 8022637B417 for ; Thu, 25 Apr 2002 00:32:10 -0700 (PDT) Received: from blossom.cjclark.org ([12.234.91.48]) by rwcrmhc52.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020425073209.GBRJ91.rwcrmhc52.attbi.com@blossom.cjclark.org>; Thu, 25 Apr 2002 07:32:09 +0000 Received: (from cjc@localhost) by blossom.cjclark.org (8.11.6/8.11.6) id g3P7W8H31633; Thu, 25 Apr 2002 00:32:08 -0700 (PDT) (envelope-from cjc) Date: Thu, 25 Apr 2002 00:32:08 -0700 From: "Crist J. Clark" To: Johan Karlsson Cc: freebsd-arch@FreeBSD.ORG Subject: Re: NOSUID and NOSUID_prog make knobs Message-ID: <20020425003208.D30779@blossom.cjclark.org> References: <20020425035353.A73613@numeri.campus.luth.se> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20020425035353.A73613@numeri.campus.luth.se>; from k@numeri.campus.luth.se on Thu, Apr 25, 2002 at 03:53:53AM +0200 X-URL: http://people.freebsd.org/~cjc/ Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Thu, Apr 25, 2002 at 03:53:53AM +0200, Johan Karlsson wrote: [snip] Ick. > Index: share/examples/etc/make.conf > =================================================================== > RCS file: /home/ncvs/src/share/examples/etc/make.conf,v > retrieving revision 1.186 > diff -u -r1.186 make.conf > --- share/examples/etc/make.conf 2002/04/23 23:59:51 1.186 > +++ share/examples/etc/make.conf 2002/04/25 01:29:12 > @@ -88,6 +88,22 @@ > # To enable installing ssh(1) with the setuid bit turned on > #ENABLE_SUID_SSH= true > # > +# To avoid installing various parts with the setuid/setgid bit turned on > +# > +#NOSUID= true # no setuid bit for any of the below > +#NOSUID_AT= true # no setuid bit for at > +#NOSUID_CHPASS= true # no setuid bit for chpass > +#NOSUID_K5SU= true # no setuid bit for k5su > +#NOSUID_PING= true # no setuid bit for ping > +#NOSUID_PING6= true # no setuid bit for ping6 > +#NOSUID_PPP= true # no setuid bit for ppp > +#NOSUID_RCP= true # no setuid bit for rcp > +#NOSUID_SHUTDOWN= true # no setuid bit for shutdown > +# > +#NOSGID= true # no setgid bit for any of the below > +#NOSGID_DM= true # no setgid bit for dm > +#NOSGID_PS= true # no setgid bit for ps ps(1) isn't setgid. [snip] > Index: bin/rcp/Makefile > =================================================================== > RCS file: /home/ncvs/src/bin/rcp/Makefile,v > retrieving revision 1.20 > diff -u -r1.20 Makefile > --- bin/rcp/Makefile 2002/04/18 07:01:34 1.20 > +++ bin/rcp/Makefile 2002/04/25 01:29:36 > @@ -21,8 +21,10 @@ > .PATH: ${.CURDIR}/../../crypto/kerberosIV/appl/bsd > .endif > > +.if !defined(NOSUID) && !defined(NOSUID_RCP) > BINOWN= root > BINMODE=4555 > INSTALLFLAGS=-fschg > +.endif > > .include This is a very painful, and difficult to maintain, way to do it. It would be much better if it could be done inside the bsd.*.mk files. I also think only then does there even exist a slim chance someone would commit this. There are way too many make.conf(5) knobs already. There are plenty of ways to customize your own installations without having to add all of your localizations to FreeBSD itself. -- Crist J. Clark | cjclark@alum.mit.edu | cjclark@jhu.edu http://people.freebsd.org/~cjc/ | cjc@freebsd.org To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Apr 25 3:31:23 2002 Delivered-To: freebsd-arch@freebsd.org Received: from south.nanolink.com (south.nanolink.com [217.75.134.10]) by hub.freebsd.org (Postfix) with SMTP id 979E437B416 for ; Thu, 25 Apr 2002 03:31:15 -0700 (PDT) Received: (qmail 12005 invoked from network); 25 Apr 2002 10:37:00 -0000 Received: from unknown (HELO straylight.ringlet.net) (212.116.140.125) by south.nanolink.com with SMTP; 25 Apr 2002 10:37:00 -0000 Received: (qmail 9459 invoked by uid 1000); 25 Apr 2002 10:30:50 -0000 Date: Thu, 25 Apr 2002 13:30:50 +0300 From: Peter Pentchev To: Jason DiCioccio Cc: freebsd-arch@freebsd.org Subject: Re: Fwd: NOSUID and NOSUID_prog make knobs Message-ID: <20020425133050.B360@straylight.oblivion.bg> Mail-Followup-To: Jason DiCioccio , freebsd-arch@freebsd.org References: <0F346F4F-580D-11D6-8E6E-00039390808C@bluenugget.net> Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-md5; protocol="application/pgp-signature"; boundary="98e8jtXdkpgskNou" Content-Disposition: inline User-Agent: Mutt/1.2.5.1i In-Reply-To: <0F346F4F-580D-11D6-8E6E-00039390808C@bluenugget.net>; from jd@bluenugget.net on Wed, Apr 24, 2002 at 10:26:56PM -0700 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG --98e8jtXdkpgskNou Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Wed, Apr 24, 2002 at 10:26:56PM -0700, Jason DiCioccio wrote: > On Wednesday, April 24, 2002, at 08:17 PM, Johan Karlsson wrote: > > On Wed, Apr 24, 2002 at 19:17 (-0700) +0000, David O'Brien wrote: > >> > >> Either do them all, or none. This flag per binary does not scale, nor= =20 > >> do > >> I see any significant portion of our userbase utilizing the=20 > >> granularity. > > > > In the discussion on -security I got the impression that the > > granularity is wanted. > > > > There are currently 29 suid and 14 sgid bits set it Makefile:s > > that would be effected by this. > > Some of them make sence to group togather e.g. lpr, ping, etc > > > > I think it just makes more sence to provide all of them > > (some grouped) than to only have 1 knob for all of them. > > > > /Johan K > > > Granularity is wanted, at least by me and others I have spoken to. I=20 > don't know if it is best to clutter make.conf or if there is a better=20 > place, or a new place, that these knobs could be placed. However, if=20 > you're going to provide the flexibility I would think you should go all= =20 > the way with it. Perhaps provide some canned sets, and/or the ability=20 > to make 'groups' of binaries in the configuration but there definitely=20 > has to be the ability to configure it to the level of individual=20 > binaries. >=20 > IMHO :) I agree that granularity would be a good thing; how about something else though, something like the following: NOSUID_LIST=3D passwd chsh chfn =2E.and then, in usr.bin/passwd/Makefile.. =2Eif "${NOSUID_LIST:Mpasswd}" =3D=3D "" BINMODE=3D 4555 =2Eendif Alternatively, the NOSUID_LIST may be turned into SUID_LIST, but that might pose problems with its default value. G'luck, Peter --=20 Peter Pentchev roam@ringlet.net roam@FreeBSD.org PGP key: http://people.FreeBSD.org/~roam/roam.key.asc Key fingerprint FDBA FD79 C26F 3C51 C95E DF9E ED18 B68D 1619 4553 If this sentence didn't exist, somebody would have invented it. --98e8jtXdkpgskNou Content-Type: application/pgp-signature Content-Disposition: inline -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (FreeBSD) Comment: For info see http://www.gnupg.org iEYEARECAAYFAjzH2tkACgkQ7Ri2jRYZRVOdHQCeKlieGJ94eGX+WZQZKVQS/ntM emUAn0a+uhTkTAdyLgAAiNZbjDvpKa5o =s4bt -----END PGP SIGNATURE----- --98e8jtXdkpgskNou-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Apr 25 9: 9:39 2002 Delivered-To: freebsd-arch@freebsd.org Received: from numeri.campus.luth.se (numeri.campus.luth.se [130.240.197.103]) by hub.freebsd.org (Postfix) with ESMTP id A05A437B416 for ; Thu, 25 Apr 2002 09:09:34 -0700 (PDT) Received: (from k@localhost) by numeri.campus.luth.se (8.11.6/8.11.6) id g3PG9HB88008; Thu, 25 Apr 2002 18:09:17 +0200 (CEST) (envelope-from k) Date: Thu, 25 Apr 2002 18:09:17 +0200 From: Johan Karlsson To: Jason DiCioccio , freebsd-arch@freebsd.org Subject: Re: Fwd: NOSUID and NOSUID_prog make knobs Message-ID: <20020425180917.A87869@numeri.campus.luth.se> References: <0F346F4F-580D-11D6-8E6E-00039390808C@bluenugget.net> <20020425133050.B360@straylight.oblivion.bg> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline User-Agent: Mutt/1.2.5i In-Reply-To: <20020425133050.B360@straylight.oblivion.bg>; from roam@ringlet.net on Thu, Apr 25, 2002 at 01:30:50PM +0300 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Thu, Apr 25, 2002 at 13:30 (+0300) +0000, Peter Pentchev wrote: > I agree that granularity would be a good thing; how about something else > though, something like the following: > > NOSUID_LIST= passwd chsh chfn > > ..and then, in usr.bin/passwd/Makefile.. > > .if "${NOSUID_LIST:Mpasswd}" == "" > BINMODE= 4555 > .endif I like this idea. I'll see what I can do along those lines. I'll also try to do one version where the changes are to bsd.*.mk instead of the individual Makefile:s but I think that it will be hard to get it correct. /Johan K -- Johan Karlsson mailto:k@numeri.campus.luth.se To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Apr 25 17:11:54 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mail.rpi.edu (mail.rpi.edu [128.113.22.40]) by hub.freebsd.org (Postfix) with ESMTP id 9DA1737B404; Thu, 25 Apr 2002 17:11:43 -0700 (PDT) Received: from [128.113.24.47] (gilead.netel.rpi.edu [128.113.24.47]) by mail.rpi.edu (8.12.1/8.12.1) with ESMTP id g3Q0Bfn5025092; Thu, 25 Apr 2002 20:11:42 -0400 Mime-Version: 1.0 X-Sender: drosih@mail.rpi.edu Message-Id: In-Reply-To: References: <200202091752.g19HqFP11551@green.bikeshed.org> <20020210040158.A26957@chiark.greenend.org.uk> Date: Thu, 25 Apr 2002 20:11:40 -0400 To: arch@FreeBSD.ORG From: Garance A Drosihn Subject: Re: diff & patch problem with 'No newline' Cc: "M. Warner Losh" , freebsd-standards@FreeBSD.ORG Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.3 (www dot roaringpenguin dot com slash mimedefang) Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Back in February, there was a discussion on the freebsd-standards list about the behavor of freebsd's 'diff' and 'patch' with respect to files which do not have a final newline character. The latest gnu-diff command will create a patch which includes the line: \ No newline at end of file if the last line of the file is changed, and if it does not have a newline character. Our 'diff' does not do this, because we specifically changed it to not do this. This was done because our older version of patch does not know what to do with the line. Back at the time, I blithely said: At 11:20 PM -0500 2/9/02, Garance A Drosihn wrote: >At 4:01 AM +0000 2/10/02, Tony Finch wrote: >>It is also useful to refer to `patch` when we talk about >>`diff`, since the former is defined (in SUS) in terms of >>the latter. And you also must consider how these tools >>interact with the revision management systems that the >>project uses. > >This is true. As I mentioned, if we need to fix patch to >understand the extra line, then we should do that. Chances >are we should do that anyway, in case someone sends us a >patch generated from the diff on the list of operating >systems I listed as 'group 5'. > >If no other operating system had this extra marker line, >then I would be reluctant to have FreeBSD add it. However, >given how much of the unix world considers that extra line >as "standard", including the two other BSD's, then I think >it's a good idea for us to also support it. And now, a mere two months later, I finally looked into it. Changing 'diff' is trivial, but the main issue is changing 'patch' to match. I found out that NetBSD had made changes to 'patch' so it does understand these lines. I copy&pasted those changes into our version, and it looks like it works right. The patch is pretty straightforward, and I would like to get it into our patch in for 4.6-release (along with the minor change to 'diff'). Any objections? -- Garance Alistair Drosehn = gad@gilead.netel.rpi.edu Senior Systems Programmer or gad@freebsd.org Rensselaer Polytechnic Institute or drosih@rpi.edu To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Apr 25 17:17:22 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mail.rpi.edu (mail.rpi.edu [128.113.22.40]) by hub.freebsd.org (Postfix) with ESMTP id 9A94137B404; Thu, 25 Apr 2002 17:16:43 -0700 (PDT) Received: from [128.113.24.47] (gilead.netel.rpi.edu [128.113.24.47]) by mail.rpi.edu (8.12.1/8.12.1) with ESMTP id g3Q0Gfn5126116; Thu, 25 Apr 2002 20:16:42 -0400 Mime-Version: 1.0 X-Sender: drosih@mail.rpi.edu Message-Id: In-Reply-To: References: <200202091752.g19HqFP11551@green.bikeshed.org> <20020210040158.A26957@chiark.greenend.org.uk> Date: Thu, 25 Apr 2002 20:16:40 -0400 To: arch@FreeBSD.ORG From: Garance A Drosihn Subject: Re: diff & patch problem with 'No newline' Cc: freebsd-standards@FreeBSD.ORG Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.3 (www dot roaringpenguin dot com slash mimedefang) Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG At 8:11 PM -0400 4/25/02, Garance A Drosihn wrote: >The patch is pretty straightforward, and I would like to >get it into our patch in for 4.6-release (along with the >minor change to 'diff'). Any objections? I guess it would help if I showed what the patch is... NetBSD has apparently been running with this for a few weeks. Index: pch.c =================================================================== RCS file: /home/ncvs/src/gnu/usr.bin/patch/pch.c,v retrieving revision 1.17 diff -u -r1.17 pch.c --- pch.c 2 Aug 2000 06:54:21 -0000 1.17 +++ pch.c 26 Apr 2002 00:14:33 -0000 @@ -434,6 +434,30 @@ /* about as informative as "Syntax error" in C */ } +/* + * True if the line has been discarded (i.e. it is a line saying + * "\ No newline at end of file".) + */ +static bool +remove_special_line(void) +{ + int c; + + c = fgetc(pfp); + if (c == '\\') { + do { + c = fgetc(pfp); + } while (c != EOF && c != '\n'); + + return TRUE; + } + + if (c != EOF) + fseek(pfp, -1, SEEK_CUR); + + return FALSE; +} + /* True if there is more of the current diff listing to process. */ bool @@ -641,6 +665,15 @@ p_end--; return FALSE; } + if (p_end == p_ptrn_lines) + { + if (remove_special_line()) { + int len; + + len = strlen(p_line[p_end]) - 1; + (p_line[p_end])[len] = 0; + } + } break; case '\t': case '\n': /* assume the 2 spaces got eaten */ if (repl_beginning && repl_could_be_missing && @@ -768,6 +801,14 @@ assert(fillsrc==p_end+1 || fillsrc==repl_beginning); assert(filldst==p_end+1 || filldst==repl_beginning); } + + if (p_line[p_end] != NULL) + { + if (remove_special_line()) { + p_len[p_end] -= 1; + (p_line[p_end])[p_len[p_end]] = 0; + } + } } else if (diff_type == UNI_DIFF) { long line_beginning = ftell(pfp); @@ -865,6 +906,12 @@ p_Char[fillsrc] = ch; p_line[fillsrc] = s; p_len[fillsrc++] = strlen(s); + if (fillsrc > p_ptrn_lines) { + if (remove_special_line()) { + p_len[fillsrc - 1] -= 1; + s[p_len[fillsrc - 1]] = 0; + } + } break; case '=': ch = ' '; @@ -900,6 +947,12 @@ p_Char[filldst] = ch; p_line[filldst] = s; p_len[filldst++] = strlen(s); + if (fillsrc > p_ptrn_lines) { + if (remove_special_line()) { + p_len[filldst - 1] -= 1; + s[p_len[filldst - 1]] = 0; + } + } break; default: p_end = filldst; @@ -975,6 +1028,12 @@ p_len[i] = strlen(p_line[i]); p_Char[i] = '-'; } + + if (remove_special_line()) { + p_len[i-1] -= 1; + (p_line[i-1])[p_len[i-1]] = 0; + } + if (hunk_type == 'c') { ret = pgets(buf, sizeof buf, pfp); p_input_line++; @@ -1006,6 +1065,11 @@ } p_len[i] = strlen(p_line[i]); p_Char[i] = '+'; + } + + if (remove_special_line()) { + p_len[i-1] -= 1; + (p_line[i-1])[p_len[i-1]] = 0; } } if (reverse) /* backwards patch? */ -- Garance Alistair Drosehn = gad@gilead.netel.rpi.edu Senior Systems Programmer or gad@freebsd.org Rensselaer Polytechnic Institute or drosih@rpi.edu To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Apr 25 18: 1:31 2002 Delivered-To: freebsd-arch@freebsd.org Received: from espresso.q9media.com (espresso.q9media.com [216.254.138.122]) by hub.freebsd.org (Postfix) with ESMTP id 25D0537B405; Thu, 25 Apr 2002 18:01:26 -0700 (PDT) Received: (from mike@localhost) by espresso.q9media.com (8.11.6/8.11.6) id g3Q10Zg62607; Thu, 25 Apr 2002 21:00:35 -0400 (EDT) (envelope-from mike) Date: Thu, 25 Apr 2002 21:00:35 -0400 From: Mike Barcroft To: Garance A Drosihn Cc: arch@FreeBSD.ORG, "M. Warner Losh" , freebsd-standards@FreeBSD.ORG Subject: Re: diff & patch problem with 'No newline' Message-ID: <20020425210035.A43192@espresso.q9media.com> References: <200202091752.g19HqFP11551@green.bikeshed.org> <20020210040158.A26957@chiark.greenend.org.uk> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: ; from drosih@rpi.edu on Thu, Apr 25, 2002 at 08:11:40PM -0400 Organization: The FreeBSD Project Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Garance A Drosihn writes: > And now, a mere two months later, I finally looked into it. > Changing 'diff' is trivial, but the main issue is changing > 'patch' to match. > > I found out that NetBSD had made changes to 'patch' so it > does understand these lines. I copy&pasted those changes > into our version, and it looks like it works right. The > patch is pretty straightforward, and I would like to get > it into our patch in for 4.6-release (along with the minor > change to 'diff'). Any objections? Yes. I still maintain that files without a trailing new line are not "text files", and should therefore be treated as binary files. Even if we did consider these to be "text files", no standards that I'm aware of define the behavior for this situation, so a non-standard patch utility would be required to interpret these extensions. This would make our generated diffs unportable in the same way as some of the other vendors you mentioned as having this feature. Best regards, Mike Barcroft To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Apr 25 19:22:50 2002 Delivered-To: freebsd-arch@freebsd.org Received: from rover.village.org (rover.bsdimp.com [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id E657637B41D; Thu, 25 Apr 2002 19:22:25 -0700 (PDT) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.11.3/8.11.3) with ESMTP id g3Q2MNH93629; Thu, 25 Apr 2002 20:22:24 -0600 (MDT) (envelope-from imp@village.org) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.11.6/8.11.6) with ESMTP id g3Q2MMb44809; Thu, 25 Apr 2002 20:22:22 -0600 (MDT) (envelope-from imp@village.org) Date: Thu, 25 Apr 2002 20:22:17 -0600 (MDT) Message-Id: <20020425.202217.82927028.imp@village.org> To: mike@FreeBSD.ORG Cc: drosih@rpi.edu, arch@FreeBSD.ORG, freebsd-standards@FreeBSD.ORG Subject: Re: diff & patch problem with 'No newline' From: "M. Warner Losh" In-Reply-To: <20020425210035.A43192@espresso.q9media.com> References: <20020425210035.A43192@espresso.q9media.com> X-Mailer: Mew version 2.1 on Emacs 21.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In message: <20020425210035.A43192@espresso.q9media.com> Mike Barcroft writes: : Garance A Drosihn writes: : > And now, a mere two months later, I finally looked into it. : > Changing 'diff' is trivial, but the main issue is changing : > 'patch' to match. : > : > I found out that NetBSD had made changes to 'patch' so it : > does understand these lines. I copy&pasted those changes : > into our version, and it looks like it works right. The : > patch is pretty straightforward, and I would like to get : > it into our patch in for 4.6-release (along with the minor : > change to 'diff'). Any objections? : : Yes. I still maintain that files without a trailing new line are not : "text files", and should therefore be treated as binary files. Even : if we did consider these to be "text files", no standards that I'm : aware of define the behavior for this situation, so a non-standard : patch utility would be required to interpret these extensions. This : would make our generated diffs unportable in the same way as some of : the other vendors you mentioned as having this feature. There's lots of software (well, OK, subversion) that depends on the old, historical behavior. The historical behavior of diff has been to include the "this file doesn't end with a newline" message, not what FreeBSD hacked it to do. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Apr 25 21: 9:28 2002 Delivered-To: freebsd-arch@freebsd.org Received: from espresso.q9media.com (espresso.q9media.com [216.254.138.122]) by hub.freebsd.org (Postfix) with ESMTP id 335E837B400; Thu, 25 Apr 2002 21:09:24 -0700 (PDT) Received: (from mike@localhost) by espresso.q9media.com (8.11.6/8.11.6) id g3Q48n273410; Fri, 26 Apr 2002 00:08:49 -0400 (EDT) (envelope-from mike) Date: Fri, 26 Apr 2002 00:08:49 -0400 From: Mike Barcroft To: "M. Warner Losh" Cc: drosih@rpi.edu, arch@FreeBSD.ORG, freebsd-standards@FreeBSD.ORG Subject: Re: diff & patch problem with 'No newline' Message-ID: <20020426000849.C43192@espresso.q9media.com> References: <20020425210035.A43192@espresso.q9media.com> <20020425.202217.82927028.imp@village.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020425.202217.82927028.imp@village.org>; from imp@village.org on Thu, Apr 25, 2002 at 08:22:17PM -0600 Organization: The FreeBSD Project Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG M. Warner Losh writes: > There's lots of software (well, OK, subversion) that depends on the > old, historical behavior. The historical behavior of diff has been to > include the "this file doesn't end with a newline" message, not what > FreeBSD hacked it to do. Perhaps the people working on Subversion still have time to fix that designo before too many people start using it. Solaris 2.5.1, for instance, returns "Warning: missing newline at end of file" on stderr for this condition. Best regards, Mike Barcroft To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Apr 25 21:12:58 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mail.rpi.edu (mail.rpi.edu [128.113.22.40]) by hub.freebsd.org (Postfix) with ESMTP id E83D337B400; Thu, 25 Apr 2002 21:12:52 -0700 (PDT) Received: from [128.113.24.47] (gilead.netel.rpi.edu [128.113.24.47]) by mail.rpi.edu (8.12.1/8.12.1) with ESMTP id g3Q4Cpn5070504; Fri, 26 Apr 2002 00:12:51 -0400 Mime-Version: 1.0 X-Sender: drosih@mail.rpi.edu Message-Id: In-Reply-To: <20020425210035.A43192@espresso.q9media.com> References: <200202091752.g19HqFP11551@green.bikeshed.org> <20020210040158.A26957@chiark.greenend.org.uk> <20020425210035.A43192@espresso.q9media.com> Date: Fri, 26 Apr 2002 00:12:50 -0400 To: Mike Barcroft From: Garance A Drosihn Subject: Re: diff & patch problem with 'No newline' Cc: arch@FreeBSD.ORG, "M. Warner Losh" , freebsd-standards@FreeBSD.ORG Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.3 (www dot roaringpenguin dot com slash mimedefang) Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG At 9:00 PM -0400 4/25/02, Mike Barcroft wrote: >Garance A Drosihn writes: >> And now, a mere two months later, I finally looked into it. >> Changing 'diff' is trivial, but the main issue is changing >> 'patch' to match. >> >> I found out that NetBSD had made changes to 'patch' so it >> does understand these lines. I copy&pasted those changes >> into our version, and it looks like it works right. The >> patch is pretty straightforward, and I would like to get >> it into our patch in for 4.6-release (along with the minor >> change to 'diff'). Any objections? > >Yes. I still maintain that files without a trailing new >line are not "text files", and should therefore be treated >as binary files. Even if we did consider these to be "text >files", no standards that I'm aware of define the behavior >for this situation, so a non-standard patch utility would >be required to interpret these extensions. Well, here is a campaign speech for this little patch... :-) Adding the support to 'patch' will not break any patch which does follow the standard. If we revert the change made to 'diff' several years ago, then I admit we will occasionally create patches that are not standard. Those patches will be non-standard in a well-known and easily fixable format. This will create no insurmountable (or even difficult) problem for anyone who receives the patch. All a person has to do is delete the one line, and they will have a patch which behaves exactly the same way as the patch we currently produce. They can even do this blindly, using a filter to strip out the line. So, that's my pitch. I feel fairly strongly that there is a real advantage in following the lead of Linux (+anyone using gnu-diff) and NetBSD in this matter. How strongly do others feel that we should stick to the letter of this standard, because they feel the standard really has the right idea? And if you feel that way, then could you please explain to me what the advantage is? Can you come up with any tangible benefit of the standard which would convince a linux user to give up this non-standard extension which they have been using for at least five years? -- Garance Alistair Drosehn = gad@gilead.netel.rpi.edu Senior Systems Programmer or gad@freebsd.org Rensselaer Polytechnic Institute or drosih@rpi.edu To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Apr 25 21:13:13 2002 Delivered-To: freebsd-arch@freebsd.org Received: from rover.village.org (rover.bsdimp.com [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id 8D65E37B425; Thu, 25 Apr 2002 21:13:03 -0700 (PDT) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.11.3/8.11.3) with ESMTP id g3Q4D0H94130; Thu, 25 Apr 2002 22:13:01 -0600 (MDT) (envelope-from imp@village.org) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.11.6/8.11.6) with ESMTP id g3Q4Cwb45510; Thu, 25 Apr 2002 22:12:58 -0600 (MDT) (envelope-from imp@village.org) Date: Thu, 25 Apr 2002 22:12:45 -0600 (MDT) Message-Id: <20020425.221245.99497735.imp@village.org> To: mike@FreeBSD.ORG Cc: drosih@rpi.edu, arch@FreeBSD.ORG, freebsd-standards@FreeBSD.ORG Subject: Re: diff & patch problem with 'No newline' From: "M. Warner Losh" In-Reply-To: <20020426000849.C43192@espresso.q9media.com> References: <20020425210035.A43192@espresso.q9media.com> <20020425.202217.82927028.imp@village.org> <20020426000849.C43192@espresso.q9media.com> X-Mailer: Mew version 2.1 on Emacs 21.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In message: <20020426000849.C43192@espresso.q9media.com> Mike Barcroft writes: : M. Warner Losh writes: : > There's lots of software (well, OK, subversion) that depends on the : > old, historical behavior. The historical behavior of diff has been to : > include the "this file doesn't end with a newline" message, not what : > FreeBSD hacked it to do. : : Perhaps the people working on Subversion still have time to fix that : designo before too many people start using it. Solaris 2.5.1, for : instance, returns "Warning: missing newline at end of file" on stderr : for this condition. Subversion already powers through this by forcing the user to install gnu diff. What does POSIX.1 say about this matter? Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Apr 25 21:18: 0 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mail.rpi.edu (mail.rpi.edu [128.113.22.40]) by hub.freebsd.org (Postfix) with ESMTP id 11F9F37B417; Thu, 25 Apr 2002 21:17:48 -0700 (PDT) Received: from [128.113.24.47] (gilead.netel.rpi.edu [128.113.24.47]) by mail.rpi.edu (8.12.1/8.12.1) with ESMTP id g3Q4Hjn5531326; Fri, 26 Apr 2002 00:17:45 -0400 Mime-Version: 1.0 X-Sender: drosih@mail.rpi.edu Message-Id: In-Reply-To: <20020426000849.C43192@espresso.q9media.com> References: <20020425210035.A43192@espresso.q9media.com> <20020425.202217.82927028.imp@village.org> <20020426000849.C43192@espresso.q9media.com> Date: Fri, 26 Apr 2002 00:17:44 -0400 To: Mike Barcroft , "M. Warner Losh" From: Garance A Drosihn Subject: Re: diff & patch problem with 'No newline' Cc: arch@FreeBSD.ORG, freebsd-standards@FreeBSD.ORG Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.3 (www dot roaringpenguin dot com slash mimedefang) Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG At 12:08 AM -0400 4/26/02, Mike Barcroft wrote: >M. Warner Losh writes: > > There's lots of software (well, OK, subversion) that > > depends on the old, historical behavior. The historical > > behavior of diff has been to include the "this file > > doesn't end with a newline" message, not what FreeBSD > > hacked it to do. > >Perhaps the people working on Subversion still have time >to fix that design before too many people start using it. >Solaris 2.5.1, for instance, returns "Warning: missing >newline at end of file" on stderr for this condition. They probably will fix it, by writing their own diff and their own patch. The same way other packages fix it, by requiring that the user install gnu-diff & gnu-patch. I am still wondering who it is that is better off given the standard behavior than this particular non-standard behavior. Not "better off" in the sense that "it is better to follow standards", but "better off" in the sense that it is easier to get their work done, and the sun shines brighter, and beer tastes better -- all because the standard does not allow patch+diff to handle this simple case of a file which is missing the last newline character. but that's enough from me for tonight... -- Garance Alistair Drosehn = gad@gilead.netel.rpi.edu Senior Systems Programmer or gad@freebsd.org Rensselaer Polytechnic Institute or drosih@rpi.edu To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Apr 25 21:34:57 2002 Delivered-To: freebsd-arch@freebsd.org Received: from espresso.q9media.com (espresso.q9media.com [216.254.138.122]) by hub.freebsd.org (Postfix) with ESMTP id 2147537B41F; Thu, 25 Apr 2002 21:34:50 -0700 (PDT) Received: (from mike@localhost) by espresso.q9media.com (8.11.6/8.11.6) id g3Q4YK374396; Fri, 26 Apr 2002 00:34:20 -0400 (EDT) (envelope-from mike) Date: Fri, 26 Apr 2002 00:34:20 -0400 From: Mike Barcroft To: Garance A Drosihn Cc: "M. Warner Losh" , arch@FreeBSD.ORG, freebsd-standards@FreeBSD.ORG Subject: Re: diff & patch problem with 'No newline' Message-ID: <20020426003420.D43192@espresso.q9media.com> References: <20020425210035.A43192@espresso.q9media.com> <20020425.202217.82927028.imp@village.org> <20020426000849.C43192@espresso.q9media.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: ; from drosih@rpi.edu on Fri, Apr 26, 2002 at 12:17:44AM -0400 Organization: The FreeBSD Project Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG Garance A Drosihn writes: > >Perhaps the people working on Subversion still have time > >to fix that design before too many people start using it. > >Solaris 2.5.1, for instance, returns "Warning: missing > >newline at end of file" on stderr for this condition. > > They probably will fix it, by writing their own diff and > their own patch. The same way other packages fix it, > by requiring that the user install gnu-diff & gnu-patch. It occurs to me that the name of this software is very appropriate. In any event, we'll be in good company if they decide to reject convention and go the Linux-route. > I am still wondering who it is that is better off given > the standard behavior than this particular non-standard > behavior. Not "better off" in the sense that "it is > better to follow standards", but "better off" in the > sense that it is easier to get their work done, and the > sun shines brighter, and beer tastes better -- all > because the standard does not allow patch+diff to > handle this simple case of a file which is missing the > last newline character. It may be that my reading of the specification is too strict. There's nothing in the Standard that deals with this edge case, so anything you do will be non-standard. I just happen to think, garbage in the outputted diff is the worst possible choice. Best regards, Mike Barcroft To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Apr 25 22: 3: 2 2002 Delivered-To: freebsd-arch@freebsd.org Received: from espresso.q9media.com (espresso.q9media.com [216.254.138.122]) by hub.freebsd.org (Postfix) with ESMTP id 7C81A37B419; Thu, 25 Apr 2002 22:02:56 -0700 (PDT) Received: (from mike@localhost) by espresso.q9media.com (8.11.6/8.11.6) id g3Q522975374; Fri, 26 Apr 2002 01:02:02 -0400 (EDT) (envelope-from mike) Date: Fri, 26 Apr 2002 01:02:02 -0400 From: Mike Barcroft To: "M. Warner Losh" Cc: drosih@rpi.edu, arch@FreeBSD.ORG, freebsd-standards@FreeBSD.ORG Subject: Re: diff & patch problem with 'No newline' Message-ID: <20020426010202.E43192@espresso.q9media.com> References: <20020425210035.A43192@espresso.q9media.com> <20020425.202217.82927028.imp@village.org> <20020426000849.C43192@espresso.q9media.com> <20020425.221245.99497735.imp@village.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20020425.221245.99497735.imp@village.org>; from imp@village.org on Thu, Apr 25, 2002 at 10:12:45PM -0600 Organization: The FreeBSD Project Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG M. Warner Losh writes: > In message: <20020426000849.C43192@espresso.q9media.com> > Mike Barcroft writes: > : Perhaps the people working on Subversion still have time to fix that > : designo before too many people start using it. Solaris 2.5.1, for > : instance, returns "Warning: missing newline at end of file" on stderr > : for this condition. > > Subversion already powers through this by forcing the user to install > gnu diff. That'll teach them. > What does POSIX.1 say about this matter? Nothing about this specific case, but: : STDOUT : ... : Diff Binary Output Format : In the POSIX locale, if one or both of the files being compared are : not text files, an unspecified format shall be used that contains the : pathnames of two files being compared and the string "differ". : : If both files being compared are text files, depending on the options : specified, one of the following formats shall be used to write the : differences. : ... ...where text file is defined as: : 3.392 Text File : : A file that contains characters organized into one or more lines. The : lines do not contain NUL characters and none can exceed {LINE_MAX} : bytes in length, including the . Although : IEEE Std 1003.1-2001 does not distinguish between text files and : files (see the ISO C standard), many utilities only produce : predictable or meaningful output when operating on text files. The : standard utilities that have such restrictions always specify text : files in their STDIN or INPUT FILES sections. Since the Standard doesn't allow additional output on STDOUT (with good reason, since it breaks patch), we have two ways to conform, either take the Solaris way and utilize: : STDERR : The standard error shall be used only for diagnostic messages. ...or utilize the binary output option, which I recommend since I don't consider files without trailing newlines to be text files. Best regards, Mike Barcroft To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Thu Apr 25 22:44:53 2002 Delivered-To: freebsd-arch@freebsd.org Received: from rover.village.org (rover.bsdimp.com [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id 92B6F37B404; Thu, 25 Apr 2002 22:44:46 -0700 (PDT) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.11.3/8.11.3) with ESMTP id g3Q5ijH94545; Thu, 25 Apr 2002 23:44:45 -0600 (MDT) (envelope-from imp@village.org) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.11.6/8.11.6) with ESMTP id g3Q5iib46021; Thu, 25 Apr 2002 23:44:44 -0600 (MDT) (envelope-from imp@village.org) Date: Thu, 25 Apr 2002 23:44:35 -0600 (MDT) Message-Id: <20020425.234435.29376552.imp@village.org> To: mike@FreeBSD.ORG Cc: drosih@rpi.edu, arch@FreeBSD.ORG, freebsd-standards@FreeBSD.ORG Subject: Re: diff & patch problem with 'No newline' From: "M. Warner Losh" In-Reply-To: <20020426010202.E43192@espresso.q9media.com> References: <20020426000849.C43192@espresso.q9media.com> <20020425.221245.99497735.imp@village.org> <20020426010202.E43192@espresso.q9media.com> X-Mailer: Mew version 2.1 on Emacs 21.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In message: <20020426010202.E43192@espresso.q9media.com> Mike Barcroft writes: : M. Warner Losh writes: : > In message: <20020426000849.C43192@espresso.q9media.com> : > Mike Barcroft writes: : > : Perhaps the people working on Subversion still have time to fix that : > : designo before too many people start using it. Solaris 2.5.1, for : > : instance, returns "Warning: missing newline at end of file" on stderr : > : for this condition. : > : > Subversion already powers through this by forcing the user to install : > gnu diff. : : That'll teach them. : : > What does POSIX.1 say about this matter? : : Nothing about this specific case, but: Is there a "clarification" to the standard that clarifies this? I don't recall the name of the clarifications, but I think that Garrett has submitted them. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Apr 26 0: 3:24 2002 Delivered-To: freebsd-arch@freebsd.org Received: from flood.ping.uio.no (flood.ping.uio.no [129.240.78.31]) by hub.freebsd.org (Postfix) with ESMTP id 8174437B416 for ; Fri, 26 Apr 2002 00:02:07 -0700 (PDT) Received: by flood.ping.uio.no (Postfix, from userid 2602) id B92B45346; Fri, 26 Apr 2002 09:02:02 +0200 (CEST) X-URL: http://www.ofug.org/~des/ X-Disclaimer: The views expressed in this message do not necessarily coincide with those of any organisation or company with which I am or have been affiliated. To: arch@freebsd.org Subject: caddr_t / char * -> void * From: Dag-Erling Smorgrav Date: 26 Apr 2002 09:02:00 +0200 Message-ID: Lines: 11 User-Agent: Gnus/5.0808 (Gnus v5.8.8) Emacs/21.2 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG --=-=-= The attached patch changes a number of occurrences of char * and caddr_t in the NIS code to void *. It also removes some unnecessary casts (e.g. casting the first argument of bzero() to char *). The patch passes buildworld and doesn't appear to break anything obvious. DES -- Dag-Erling Smorgrav - des@ofug.org --=-=-= Content-Type: text/x-patch Content-Disposition: attachment; filename=void.diff Change 10300 by des@des.at.des.thinksec.com on 2002/04/25 22:08:26 Spell 'void *' as 'void *'. Sponsored by: DARPA, NAI Labs Affected files ... ... //depot/user/des/pam/include/rpc/clnt.h#3 edit ... //depot/user/des/pam/include/rpc/pmap_clnt.h#3 edit ... //depot/user/des/pam/include/rpc/svc.h#4 edit ... //depot/user/des/pam/include/rpc/xdr.h#4 edit ... //depot/user/des/pam/include/rpcsvc/ypclnt.h#4 edit ... //depot/user/des/pam/lib/libc/rpc/auth_time.c#4 edit ... //depot/user/des/pam/lib/libc/rpc/clnt_dg.c#5 edit ... //depot/user/des/pam/lib/libc/rpc/clnt_raw.c#3 edit ... //depot/user/des/pam/lib/libc/rpc/clnt_vc.c#4 edit ... //depot/user/des/pam/lib/libc/rpc/crypt_client.c#4 edit ... //depot/user/des/pam/lib/libc/rpc/key_call.c#4 edit ... //depot/user/des/pam/lib/libc/rpc/svc.c#3 edit ... //depot/user/des/pam/lib/libc/rpc/svc_dg.c#3 edit ... //depot/user/des/pam/lib/libc/rpc/svc_raw.c#3 edit ... //depot/user/des/pam/lib/libc/rpc/svc_vc.c#4 edit ... //depot/user/des/pam/lib/libc/xdr/xdr.c#3 edit ... //depot/user/des/pam/lib/libc/xdr/xdr_rec.c#3 edit ... //depot/user/des/pam/lib/libc/yp/xdryp.c#4 edit ... //depot/user/des/pam/lib/libc/yp/yplib.c#5 edit ... //depot/user/des/pam/libexec/rpc.rquotad/rquotad.c#3 edit ... //depot/user/des/pam/libexec/rpc.rstatd/rstat_proc.c#3 edit ... //depot/user/des/pam/libexec/rpc.rusersd/rusers_proc.c#3 edit ... //depot/user/des/pam/libexec/rpc.rwalld/rwalld.c#4 edit ... //depot/user/des/pam/libexec/rpc.sprayd/sprayd.c#3 edit ... //depot/user/des/pam/libexec/ypxfr/ypxfr_getmap.c#4 edit ... //depot/user/des/pam/libexec/ypxfr/ypxfr_misc.c#5 edit ... //depot/user/des/pam/usr.sbin/keyserv/keyserv.c#3 edit ... //depot/user/des/pam/usr.sbin/rpc.ypxfrd/ypxfrd_server.c#3 edit ... //depot/user/des/pam/usr.sbin/spray/spray.c#2 edit ... //depot/user/des/pam/usr.sbin/yp_mkdb/yp_mkdb.c#3 edit ... //depot/user/des/pam/usr.sbin/ypbind/yp_ping.c#4 edit ... //depot/user/des/pam/usr.sbin/ypbind/ypbind.c#3 edit ... //depot/user/des/pam/usr.sbin/yppush/yppush_main.c#4 edit ... //depot/user/des/pam/usr.sbin/ypserv/yp_dblookup.c#4 edit ... //depot/user/des/pam/usr.sbin/ypserv/yp_server.c#3 edit ... //depot/user/des/pam/usr.sbin/ypset/ypset.c#3 edit Differences ... ==== //depot/user/des/pam/include/rpc/clnt.h#3 (text+ko) ==== @@ -98,8 +98,8 @@ struct clnt_ops { /* call remote procedure */ enum clnt_stat (*cl_call)(struct __rpc_client *, - rpcproc_t, xdrproc_t, caddr_t, xdrproc_t, - caddr_t, struct timeval); + rpcproc_t, xdrproc_t, void *, xdrproc_t, + void *, struct timeval); /* abort a call */ void (*cl_abort)(struct __rpc_client *); /* get specific error code */ @@ -107,12 +107,12 @@ struct rpc_err *); /* frees results */ bool_t (*cl_freeres)(struct __rpc_client *, - xdrproc_t, caddr_t); + xdrproc_t, void *); /* destroy this structure */ void (*cl_destroy)(struct __rpc_client *); /* the ioctl() of rpc */ bool_t (*cl_control)(struct __rpc_client *, u_int, - char *); + void *); } *cl_ops; void *cl_private; /* private stuff */ char *cl_netid; /* network token */ @@ -155,17 +155,17 @@ * CLIENT *rh; * rpcproc_t proc; * xdrproc_t xargs; - * caddr_t argsp; + * void *argsp; * xdrproc_t xres; - * caddr_t resp; + * void *resp; * struct timeval timeout; */ #define CLNT_CALL(rh, proc, xargs, argsp, xres, resp, secs) \ ((*(rh)->cl_ops->cl_call)(rh, proc, xargs, \ - (caddr_t)(void *)argsp, xres, (caddr_t)(void *)resp, secs)) + argsp, xres, resp, secs)) #define clnt_call(rh, proc, xargs, argsp, xres, resp, secs) \ ((*(rh)->cl_ops->cl_call)(rh, proc, xargs, \ - (caddr_t)(void *)argsp, xres, (caddr_t)(void *)resp, secs)) + argsp, xres, resp, secs)) /* * void @@ -189,7 +189,7 @@ * CLNT_FREERES(rh, xres, resp); * CLIENT *rh; * xdrproc_t xres; - * caddr_t resp; + * void *resp; */ #define CLNT_FREERES(rh,xres,resp) ((*(rh)->cl_ops->cl_freeres)(rh,xres,resp)) #define clnt_freeres(rh,xres,resp) ((*(rh)->cl_ops->cl_freeres)(rh,xres,resp)) ==== //depot/user/des/pam/include/rpc/pmap_clnt.h#3 (text+ko) ==== @@ -76,8 +76,8 @@ xdrproc_t, caddr_t, struct timeval, u_long *); extern enum clnt_stat clnt_broadcast(u_long, u_long, u_long, - xdrproc_t, char *, - xdrproc_t, char *, + xdrproc_t, void *, + xdrproc_t, void *, resultproc_t); extern u_short pmap_getport(struct sockaddr_in *, u_long, u_long, u_int); ==== //depot/user/des/pam/include/rpc/svc.h#4 (text+ko) ==== @@ -91,12 +91,12 @@ enum xprt_stat (*xp_stat)(struct __rpc_svcxprt *); /* get arguments */ bool_t (*xp_getargs)(struct __rpc_svcxprt *, xdrproc_t, - caddr_t); + void *); /* send reply */ bool_t (*xp_reply)(struct __rpc_svcxprt *, struct rpc_msg *); /* free mem allocated for args */ bool_t (*xp_freeargs)(struct __rpc_svcxprt *, xdrproc_t, - caddr_t); + void *); /* destroy this struct */ void (*xp_destroy)(struct __rpc_svcxprt *); } *xp_ops; @@ -147,7 +147,7 @@ * SVCXPRT *xprt; * struct rpc_msg *msg; * xdrproc_t xargs; - * caddr_t argsp; + * void * argsp; */ #define SVC_RECV(xprt, msg) \ (*(xprt)->xp_ops->xp_recv)((xprt), (msg)) @@ -259,7 +259,7 @@ */ __BEGIN_DECLS -extern bool_t svc_sendreply(SVCXPRT *, xdrproc_t, char *); +extern bool_t svc_sendreply(SVCXPRT *, xdrproc_t, void *); extern void svcerr_decode(SVCXPRT *); extern void svcerr_weakauth(SVCXPRT *); extern void svcerr_noproc(SVCXPRT *); ==== //depot/user/des/pam/include/rpc/xdr.h#4 (text+ko) ==== @@ -138,7 +138,7 @@ /* * XXX can't actually prototype it, because some take three args!!! */ -typedef bool_t (*xdrproc_t)(/* XDR *, void *, u_int */); +typedef bool_t (*xdrproc_t)(XDR *, ...); #endif /* @@ -314,7 +314,7 @@ extern bool_t xdr_reference(XDR *, char **, u_int, xdrproc_t); extern bool_t xdr_pointer(XDR *, char **, u_int, xdrproc_t); extern bool_t xdr_wrapstring(XDR *, char **); -extern void xdr_free(xdrproc_t, char *); +extern void xdr_free(xdrproc_t, void *); extern bool_t xdr_hyper(XDR *, quad_t *); extern bool_t xdr_u_hyper(XDR *, u_quad_t *); extern bool_t xdr_longlong_t(XDR *, quad_t *); @@ -347,9 +347,9 @@ #endif /* XDR pseudo records for tcp */ -extern void xdrrec_create(XDR *, u_int, u_int, char *, - int (*)(char *, char *, int), - int (*)(char *, char *, int)); +extern void xdrrec_create(XDR *, u_int, u_int, void *, + int (*)(void *, void *, int), + int (*)(void *, void *, int)); /* make end of xdr record */ extern bool_t xdrrec_endofrecord(XDR *, int); ==== //depot/user/des/pam/include/rpcsvc/ypclnt.h#4 (text+ko) ==== @@ -81,8 +81,8 @@ int yp_master(char *indomain, char *inmap, char **outname); int yp_order(char *indomain, char *inmap, int *outorder); int yp_all(char *indomain, char *inmap, struct ypall_callback *incallback); -char * yperr_string(int incode); -char * ypbinderr_string(int incode); +const char *yperr_string(int incode); +const char *ypbinderr_string(int incode); int ypprot_err(unsigned int incode); __END_DECLS ==== //depot/user/des/pam/lib/libc/rpc/auth_time.c#4 (text+ko) ==== @@ -343,8 +343,8 @@ tv.tv_sec = 5; tv.tv_usec = 0; time_valid = 0; - status = clnt_call(clnt, RPCBPROC_GETTIME, xdr_void, NULL, - xdr_u_long, (char *)&thetime, tv); + status = clnt_call(clnt, RPCBPROC_GETTIME, (xdrproc_t)xdr_void, NULL, + (xdrproc_t)xdr_u_long, &thetime, tv); /* * The only error we check for is anything but success. In * fact we could have seen PROGMISMATCH if talking to a 4.1 ==== //depot/user/des/pam/lib/libc/rpc/clnt_dg.c#5 (text+ko) ==== @@ -68,10 +68,10 @@ static struct clnt_ops *clnt_dg_ops(void); static bool_t time_not_ok(struct timeval *); -static enum clnt_stat clnt_dg_call(CLIENT *, rpcproc_t, xdrproc_t, caddr_t, - xdrproc_t, caddr_t, struct timeval); +static enum clnt_stat clnt_dg_call(CLIENT *, rpcproc_t, xdrproc_t, void *, + xdrproc_t, void *, struct timeval); static void clnt_dg_geterr(CLIENT *, struct rpc_err *); -static bool_t clnt_dg_freeres(CLIENT *, xdrproc_t, caddr_t); +static bool_t clnt_dg_freeres(CLIENT *, xdrproc_t, void *); static void clnt_dg_abort(CLIENT *); static bool_t clnt_dg_control(CLIENT *, u_int, char *); static void clnt_dg_destroy(CLIENT *); @@ -294,9 +294,9 @@ CLIENT *cl; /* client handle */ rpcproc_t proc; /* procedure number */ xdrproc_t xargs; /* xdr routine for args */ - caddr_t argsp; /* pointer to args */ + void *argsp; /* pointer to args */ xdrproc_t xresults; /* xdr routine for results */ - caddr_t resultsp; /* pointer to results */ + void *resultsp; /* pointer to results */ struct timeval utimeout; /* seconds to wait before giving up */ { struct cu_data *cu = (struct cu_data *)cl->cl_private; @@ -594,7 +594,7 @@ clnt_dg_freeres(cl, xdr_res, res_ptr) CLIENT *cl; xdrproc_t xdr_res; - caddr_t res_ptr; + void *res_ptr; { struct cu_data *cu = (struct cu_data *)cl->cl_private; XDR *xdrs = &(cu->cu_outxdrs); ==== //depot/user/des/pam/lib/libc/rpc/clnt_raw.c#3 (text+ko) ==== @@ -76,10 +76,10 @@ u_int mcnt; } *clntraw_private; -static enum clnt_stat clnt_raw_call(CLIENT *, rpcproc_t, xdrproc_t, caddr_t, - xdrproc_t, caddr_t, struct timeval); +static enum clnt_stat clnt_raw_call(CLIENT *, rpcproc_t, xdrproc_t, void *, + xdrproc_t, void *, struct timeval); static void clnt_raw_geterr(CLIENT *, struct rpc_err *); -static bool_t clnt_raw_freeres(CLIENT *, xdrproc_t, caddr_t); +static bool_t clnt_raw_freeres(CLIENT *, xdrproc_t, void *); static void clnt_raw_abort(CLIENT *); static bool_t clnt_raw_control(CLIENT *, u_int, char *); static void clnt_raw_destroy(CLIENT *); @@ -145,9 +145,9 @@ CLIENT *h; rpcproc_t proc; xdrproc_t xargs; - caddr_t argsp; + void *argsp; xdrproc_t xresults; - caddr_t resultsp; + void *resultsp; struct timeval timeout; { struct clntraw_private *clp = clntraw_private; @@ -251,7 +251,7 @@ clnt_raw_freeres(cl, xdr_res, res_ptr) CLIENT *cl; xdrproc_t xdr_res; - caddr_t res_ptr; + void *res_ptr; { struct clntraw_private *clp = clntraw_private; XDR *xdrs = &clp->xdr_stream; ==== //depot/user/des/pam/lib/libc/rpc/clnt_vc.c#4 (text+ko) ==== @@ -87,17 +87,17 @@ struct cmsgcred cmcred; }; -static enum clnt_stat clnt_vc_call(CLIENT *, rpcproc_t, xdrproc_t, caddr_t, - xdrproc_t, caddr_t, struct timeval); +static enum clnt_stat clnt_vc_call(CLIENT *, rpcproc_t, xdrproc_t, void *, + xdrproc_t, void *, struct timeval); static void clnt_vc_geterr(CLIENT *, struct rpc_err *); -static bool_t clnt_vc_freeres(CLIENT *, xdrproc_t, caddr_t); +static bool_t clnt_vc_freeres(CLIENT *, xdrproc_t, void *); static void clnt_vc_abort(CLIENT *); static bool_t clnt_vc_control(CLIENT *, u_int, char *); static void clnt_vc_destroy(CLIENT *); static struct clnt_ops *clnt_vc_ops(void); static bool_t time_not_ok(struct timeval *); -static int read_vc(caddr_t, caddr_t, int); -static int write_vc(caddr_t, caddr_t, int); +static int read_vc(void *, void *, int); +static int write_vc(void *, void *, int); static int __msgwrite(int, void *, size_t); static int __msgread(int, void *, size_t); @@ -304,10 +304,10 @@ if (ct) { if (ct->ct_addr.len) mem_free(ct->ct_addr.buf, ct->ct_addr.len); - mem_free((caddr_t)ct, sizeof (struct ct_data)); + mem_free(ct, sizeof (struct ct_data)); } if (cl) - mem_free((caddr_t)cl, sizeof (CLIENT)); + mem_free(cl, sizeof (CLIENT)); } return ((CLIENT *)NULL); } @@ -317,9 +317,9 @@ CLIENT *cl; rpcproc_t proc; xdrproc_t xdr_args; - caddr_t args_ptr; + void *args_ptr; xdrproc_t xdr_results; - caddr_t results_ptr; + void *results_ptr; struct timeval timeout; { struct ct_data *ct = (struct ct_data *) cl->cl_private; @@ -457,7 +457,7 @@ clnt_vc_freeres(cl, xdr_res, res_ptr) CLIENT *cl; xdrproc_t xdr_res; - caddr_t res_ptr; + void *res_ptr; { struct ct_data *ct; XDR *xdrs; @@ -660,13 +660,13 @@ */ static int read_vc(ctp, buf, len) - caddr_t ctp; - caddr_t buf; + void *ctp; + void *buf; int len; { struct sockaddr sa; socklen_t sal; - struct ct_data *ct = (struct ct_data *)(void *)ctp; + struct ct_data *ct = (struct ct_data *)ctp; struct pollfd fd; int milliseconds = (int)((ct->ct_wait.tv_sec * 1000) + (ct->ct_wait.tv_usec / 1000)); @@ -717,13 +717,13 @@ static int write_vc(ctp, buf, len) - caddr_t ctp; - caddr_t buf; + void *ctp; + void *buf; int len; { struct sockaddr sa; socklen_t sal; - struct ct_data *ct = (struct ct_data *)(void *)ctp; + struct ct_data *ct = (struct ct_data *)ctp; int i, cnt; sal = sizeof(sa); ==== //depot/user/des/pam/lib/libc/rpc/crypt_client.c#4 (text+ko) ==== @@ -93,7 +93,7 @@ bcopy(result_1->des_ivec, dparms->des_ivec, 8); } - clnt_freeres(clnt, xdr_desresp, (char *)result_1); + clnt_freeres(clnt, (xdrproc_t)xdr_desresp, result_1); clnt_destroy(clnt); return(stat); ==== //depot/user/des/pam/lib/libc/rpc/key_call.c#4 (text+ko) ==== @@ -86,7 +86,7 @@ cryptkeyres *(*__key_decryptsession_pk_LOCAL)() = 0; des_block *(*__key_gendes_LOCAL)() = 0; -static int key_call( u_long, xdrproc_t, char *, xdrproc_t, char * ); +static int key_call( u_long, xdrproc_t, void *, xdrproc_t, void *); int key_setsecret(secretkey) @@ -94,8 +94,8 @@ { keystatus status; - if (!key_call((u_long) KEY_SET, xdr_keybuf, (char *) secretkey, - xdr_keystatus, (char *)&status)) { + if (!key_call((u_long) KEY_SET, (xdrproc_t)xdr_keybuf, secretkey, + (xdrproc_t)xdr_keystatus, &status)) { return (-1); } if (status != KEY_SUCCESS) { @@ -119,8 +119,8 @@ struct key_netstres kres; memset((void*)&kres, 0, sizeof (kres)); - if (key_call((u_long) KEY_NET_GET, xdr_void, (char *)NULL, - xdr_key_netstres, (char *) &kres) && + if (key_call((u_long) KEY_NET_GET, (xdrproc_t)xdr_void, NULL, + (xdrproc_t)xdr_key_netstres, &kres) && (kres.status == KEY_SUCCESS) && (kres.key_netstres_u.knet.st_priv_key[0] != 0)) { /* avoid leaving secret key in memory */ @@ -142,8 +142,8 @@ arg.remotename = remotename; arg.remotekey = *remotekey; arg.deskey = *deskey; - if (!key_call((u_long)KEY_ENCRYPT_PK, xdr_cryptkeyarg2, (char *)&arg, - xdr_cryptkeyres, (char *)&res)) { + if (!key_call((u_long)KEY_ENCRYPT_PK, (xdrproc_t)xdr_cryptkeyarg2, &arg, + (xdrproc_t)xdr_cryptkeyres, &res)) { return (-1); } if (res.status != KEY_SUCCESS) { @@ -166,8 +166,8 @@ arg.remotename = remotename; arg.remotekey = *remotekey; arg.deskey = *deskey; - if (!key_call((u_long)KEY_DECRYPT_PK, xdr_cryptkeyarg2, (char *)&arg, - xdr_cryptkeyres, (char *)&res)) { + if (!key_call((u_long)KEY_DECRYPT_PK, (xdrproc_t)xdr_cryptkeyarg2, &arg, + (xdrproc_t)xdr_cryptkeyres, &res)) { return (-1); } if (res.status != KEY_SUCCESS) { @@ -188,8 +188,8 @@ arg.remotename = (char *) remotename; arg.deskey = *deskey; - if (!key_call((u_long)KEY_ENCRYPT, xdr_cryptkeyarg, (char *)&arg, - xdr_cryptkeyres, (char *)&res)) { + if (!key_call((u_long)KEY_ENCRYPT, (xdrproc_t)xdr_cryptkeyarg, &arg, + (xdrproc_t)xdr_cryptkeyres, &res)) { return (-1); } if (res.status != KEY_SUCCESS) { @@ -210,8 +210,8 @@ arg.remotename = (char *) remotename; arg.deskey = *deskey; - if (!key_call((u_long)KEY_DECRYPT, xdr_cryptkeyarg, (char *)&arg, - xdr_cryptkeyres, (char *)&res)) { + if (!key_call((u_long)KEY_DECRYPT, (xdrproc_t)xdr_cryptkeyarg, &arg, + (xdrproc_t)xdr_cryptkeyres, &res)) { return (-1); } if (res.status != KEY_SUCCESS) { @@ -226,8 +226,8 @@ key_gendes(key) des_block *key; { - if (!key_call((u_long)KEY_GEN, xdr_void, (char *)NULL, - xdr_des_block, (char *)key)) { + if (!key_call((u_long)KEY_GEN, (xdrproc_t)xdr_void, NULL, + (xdrproc_t)xdr_des_block, key)) { return (-1); } return (0); @@ -240,8 +240,8 @@ keystatus status; - if (!key_call((u_long) KEY_NET_PUT, xdr_key_netstarg, (char *) arg, - xdr_keystatus, (char *) &status)){ + if (!key_call((u_long) KEY_NET_PUT, (xdrproc_t)xdr_key_netstarg, arg, + (xdrproc_t)xdr_keystatus, &status)){ return (-1); } @@ -260,8 +260,8 @@ { cryptkeyres res; - if (!key_call((u_long) KEY_GET_CONV, xdr_keybuf, pkey, - xdr_cryptkeyres, (char *)&res)) { + if (!key_call((u_long) KEY_GET_CONV, (xdrproc_t)xdr_keybuf, pkey, + (xdrproc_t)xdr_cryptkeyres, &res)) { return (-1); } if (res.status != KEY_SUCCESS) { @@ -427,9 +427,9 @@ key_call(proc, xdr_arg, arg, xdr_rslt, rslt) u_long proc; xdrproc_t xdr_arg; - char *arg; + void *arg; xdrproc_t xdr_rslt; - char *rslt; + void *rslt; { CLIENT *clnt; struct timeval wait_time; ==== //depot/user/des/pam/lib/libc/rpc/svc.c#3 (text+ko) ==== @@ -360,7 +360,7 @@ svc_sendreply(xprt, xdr_results, xdr_location) SVCXPRT *xprt; xdrproc_t xdr_results; - caddr_t xdr_location; + void * xdr_location; { struct rpc_msg rply; @@ -443,7 +443,7 @@ u_long tmp; tmp = ((u_long) xprt->xp_p3) | SVC_VERSQUIET; - xprt->xp_p3 = (caddr_t) tmp; + xprt->xp_p3 = tmp; } void @@ -453,7 +453,7 @@ u_long tmp; tmp = ((u_long) xprt->xp_p3) & ~SVC_VERSQUIET; - xprt->xp_p3 = (caddr_t) tmp; + xprt->xp_p3 = tmp; } void ==== //depot/user/des/pam/lib/libc/rpc/svc_dg.c#3 (text+ko) ==== @@ -74,8 +74,8 @@ static enum xprt_stat svc_dg_stat(SVCXPRT *); static bool_t svc_dg_recv(SVCXPRT *, struct rpc_msg *); static bool_t svc_dg_reply(SVCXPRT *, struct rpc_msg *); -static bool_t svc_dg_getargs(SVCXPRT *, xdrproc_t, caddr_t); -static bool_t svc_dg_freeargs(SVCXPRT *, xdrproc_t, caddr_t); +static bool_t svc_dg_getargs(SVCXPRT *, xdrproc_t, void *); +static bool_t svc_dg_freeargs(SVCXPRT *, xdrproc_t, void *); static void svc_dg_destroy(SVCXPRT *); static bool_t svc_dg_control(SVCXPRT *, const u_int, void *); static int cache_get(SVCXPRT *, struct rpc_msg *, char **, size_t *); @@ -137,7 +137,7 @@ XDR_DECODE); su->su_cache = NULL; xprt->xp_fd = fd; - xprt->xp_p2 = (caddr_t)(void *)su; + xprt->xp_p2 = su; xprt->xp_verf.oa_base = su->su_verfbody; svc_dg_ops(xprt); xprt->xp_rtaddr.maxlen = sizeof (struct sockaddr_storage); @@ -250,7 +250,7 @@ svc_dg_getargs(xprt, xdr_args, args_ptr) SVCXPRT *xprt; xdrproc_t xdr_args; - caddr_t args_ptr; + void *args_ptr; { return (*xdr_args)(&(su_data(xprt)->su_xdrs), args_ptr); } @@ -259,7 +259,7 @@ svc_dg_freeargs(xprt, xdr_args, args_ptr) SVCXPRT *xprt; xdrproc_t xdr_args; - caddr_t args_ptr; + void *args_ptr; { XDR *xdrs = &(su_data(xprt)->su_xdrs); ==== //depot/user/des/pam/lib/libc/rpc/svc_raw.c#3 (text+ko) ==== @@ -75,8 +75,8 @@ static enum xprt_stat svc_raw_stat(SVCXPRT *); static bool_t svc_raw_recv(SVCXPRT *, struct rpc_msg *); static bool_t svc_raw_reply(SVCXPRT *, struct rpc_msg *); -static bool_t svc_raw_getargs(SVCXPRT *, xdrproc_t, caddr_t); -static bool_t svc_raw_freeargs(SVCXPRT *, xdrproc_t, caddr_t); +static bool_t svc_raw_getargs(SVCXPRT *, xdrproc_t, void *); +static bool_t svc_raw_freeargs(SVCXPRT *, xdrproc_t, void *); static void svc_raw_destroy(SVCXPRT *); static void svc_raw_ops(SVCXPRT *); static bool_t svc_raw_control(SVCXPRT *, const u_int, void *); @@ -179,7 +179,7 @@ svc_raw_getargs(xprt, xdr_args, args_ptr) SVCXPRT *xprt; xdrproc_t xdr_args; - caddr_t args_ptr; + void *args_ptr; { struct svc_raw_private *srp; @@ -198,7 +198,7 @@ svc_raw_freeargs(xprt, xdr_args, args_ptr) SVCXPRT *xprt; xdrproc_t xdr_args; - caddr_t args_ptr; + void *args_ptr; { struct svc_raw_private *srp; XDR *xdrs; ==== //depot/user/des/pam/lib/libc/rpc/svc_vc.c#4 (text+ko) ==== @@ -77,12 +77,12 @@ static bool_t rendezvous_request(SVCXPRT *, struct rpc_msg *); static enum xprt_stat rendezvous_stat(SVCXPRT *); static void svc_vc_destroy(SVCXPRT *); -static int read_vc(caddr_t, caddr_t, int); -static int write_vc(caddr_t, caddr_t, int); +static int read_vc(void *, void *, int); +static int write_vc(void *, void *, int); static enum xprt_stat svc_vc_stat(SVCXPRT *); static bool_t svc_vc_recv(SVCXPRT *, struct rpc_msg *); -static bool_t svc_vc_getargs(SVCXPRT *, xdrproc_t, caddr_t); -static bool_t svc_vc_freeargs(SVCXPRT *, xdrproc_t, caddr_t); +static bool_t svc_vc_getargs(SVCXPRT *, xdrproc_t, void *); +static bool_t svc_vc_freeargs(SVCXPRT *, xdrproc_t, void *); static bool_t svc_vc_reply(SVCXPRT *, struct rpc_msg *); static void svc_vc_rendezvous_ops(SVCXPRT *); static void svc_vc_ops(SVCXPRT *); @@ -145,7 +145,7 @@ goto cleanup_svc_vc_create; } xprt->xp_tp = NULL; - xprt->xp_p1 = (caddr_t)(void *)r; + xprt->xp_p1 = r; xprt->xp_p2 = NULL; xprt->xp_p3 = NULL; xprt->xp_verf = _null_auth; @@ -265,8 +265,8 @@ } cd->strm_stat = XPRT_IDLE; xdrrec_create(&(cd->xdrs), sendsize, recvsize, - (caddr_t)(void *)xprt, read_vc, write_vc); - xprt->xp_p1 = (caddr_t)(void *)cd; + xprt, read_vc, write_vc); + xprt->xp_p1 = cd; xprt->xp_verf.oa_base = cd->verf_body; svc_vc_ops(xprt); /* truely deals with calls */ xprt->xp_port = 0; /* this is a connection, not a rendezvouser */ @@ -389,8 +389,8 @@ */ static int read_vc(xprtp, buf, len) - caddr_t xprtp; - caddr_t buf; + void *xprtp; + void *buf; int len; { SVCXPRT *xprt; @@ -400,7 +400,7 @@ struct sockaddr *sa; struct cmessage *cm; - xprt = (SVCXPRT *)(void *)xprtp; + xprt = (SVCXPRT *)xprtp; assert(xprt != NULL); sock = xprt->xp_fd; @@ -447,15 +447,15 @@ */ static int write_vc(xprtp, buf, len) - caddr_t xprtp; - caddr_t buf; + void *xprtp; + void *buf; int len; { SVCXPRT *xprt; int i, cnt; struct sockaddr *sa; - xprt = (SVCXPRT *)(void *)xprtp; + xprt = (SVCXPRT *)xprtp; assert(xprt != NULL); sa = (struct sockaddr *)xprt->xp_rtaddr.buf; @@ -527,7 +527,7 @@ svc_vc_getargs(xprt, xdr_args, args_ptr) SVCXPRT *xprt; xdrproc_t xdr_args; - caddr_t args_ptr; + void *args_ptr; { assert(xprt != NULL); @@ -540,7 +540,7 @@ svc_vc_freeargs(xprt, xdr_args, args_ptr) SVCXPRT *xprt; xdrproc_t xdr_args; - caddr_t args_ptr; + void *args_ptr; { XDR *xdrs; @@ -613,11 +613,11 @@ ops.xp_recv = rendezvous_request; ops.xp_stat = rendezvous_stat; ops.xp_getargs = - (bool_t (*)(SVCXPRT *, xdrproc_t, caddr_t))abort; + (bool_t (*)(SVCXPRT *, xdrproc_t, void *))abort; ops.xp_reply = (bool_t (*)(SVCXPRT *, struct rpc_msg *))abort; ops.xp_freeargs = - (bool_t (*)(SVCXPRT *, xdrproc_t, caddr_t))abort, + (bool_t (*)(SVCXPRT *, xdrproc_t, void *))abort, ops.xp_destroy = svc_vc_destroy; ops2.xp_control = svc_vc_control; } @@ -687,7 +687,7 @@ msg.msg_iovlen = 1; msg.msg_name = NULL; msg.msg_namelen = 0; - msg.msg_control = (caddr_t)&cm; + msg.msg_control = &cm; msg.msg_controllen = sizeof(struct cmessage); msg.msg_flags = 0; ==== //depot/user/des/pam/lib/libc/xdr/xdr.c#3 (text+ko) ==== @@ -78,7 +78,7 @@ void xdr_free(proc, objp) xdrproc_t proc; - char *objp; + void *objp; { XDR x; @@ -90,9 +90,7 @@ * XDR nothing */ bool_t -xdr_void(/* xdrs, addr */) - /* XDR *xdrs; */ - /* caddr_t addr; */ +xdr_void(void) { return (TRUE); ==== //depot/user/des/pam/lib/libc/xdr/xdr_rec.c#3 (text+ko) ==== @@ -110,7 +110,7 @@ /* * out-goung bits */ - int (*writeit)(char *, char *, int); + int (*writeit)(void *, void *, int); char *out_base; /* output buffer (points to frag header) */ char *out_finger; /* next output position */ char *out_boundry; /* data cannot up to this address */ @@ -119,7 +119,7 @@ /* * in-coming bits */ - int (*readit)(char *, char *, int); + int (*readit)(void *, void *, int); u_long in_size; /* fixed size of the input buffer */ char *in_base; char *in_finger; /* location of next byte to be had */ @@ -152,11 +152,11 @@ XDR *xdrs; u_int sendsize; u_int recvsize; - char *tcp_handle; + void *tcp_handle; /* like read, but pass it a tcp_handle, not sock */ - int (*readit)(char *, char *, int); + int (*readit)(void *, void *, int); /* like write, but pass it a tcp_handle, not sock */ - int (*writeit)(char *, char *, int); + int (*writeit)(void *, void *, int); { RECSTREAM *rstrm = mem_alloc(sizeof(RECSTREAM)); ==== //depot/user/des/pam/lib/libc/yp/xdryp.c#4 (text+ko) ==== @@ -69,12 +69,12 @@ bzero(&out, sizeof out); while (1) { if (!xdr_ypresp_all(xdrs, &out)) { - xdr_free(xdr_ypresp_all, (char *)&out); + xdr_free((xdrproc_t)xdr_ypresp_all, &out); *objp = YP_YPERR; return (FALSE); } if (out.more == 0) { - xdr_free(xdr_ypresp_all, (char *)&out); + xdr_free((xdrproc_t)xdr_ypresp_all, &out); *objp = YP_NOMORE; return (TRUE); } @@ -89,7 +89,7 @@ bcopy(out.ypresp_all_u.val.val.valdat_val, val, out.ypresp_all_u.val.val.valdat_len); val[out.ypresp_all_u.val.val.valdat_len] = '\0'; - xdr_free(xdr_ypresp_all, (char *)&out); + xdr_free((xdrproc_t)xdr_ypresp_all, &out); r = (*ypresp_allfn)(status, key, out.ypresp_all_u.val.key.keydat_len, @@ -102,11 +102,11 @@ return (TRUE); break; case YP_NOMORE: - xdr_free(xdr_ypresp_all, (char *)&out); + xdr_free((xdrproc_t)xdr_ypresp_all, &out); *objp = YP_NOMORE; return (TRUE); default: - xdr_free(xdr_ypresp_all, (char *)&out); + xdr_free((xdrproc_t)xdr_ypresp_all, &out); *objp = status; return (TRUE); } ==== //depot/user/des/pam/lib/libc/yp/yplib.c#5 (text+ko) ==== @@ -260,7 +260,7 @@ } #endif -char * +const char * ypbinderr_string(int incode) { static char err[80]; @@ -461,7 +461,8 @@ tv.tv_sec = _yplib_timeout/2; tv.tv_usec = 0; r = clnt_call(client, YPBINDPROC_DOMAIN, - xdr_domainname, (char *)&dom, xdr_ypbind_resp, &ypbr, tv); + (xdrproc_t)xdr_domainname, &dom, + (xdrproc_t)xdr_ypbind_resp, &ypbr, tv); if (r != RPC_SUCCESS) { clnt_destroy(client); ysd->dom_vers = -1; @@ -663,7 +664,8 @@ bzero((char *)&yprv, sizeof yprv); r = clnt_call(ysd->dom_client, YPPROC_MATCH, - xdr_ypreq_key, &yprk, xdr_ypresp_val, &yprv, tv); + (xdrproc_t)xdr_ypreq_key, &yprk, + (xdrproc_t)xdr_ypresp_val, &yprv, tv); if (r != RPC_SUCCESS) { clnt_perror(ysd->dom_client, "yp_match: clnt_call"); _yp_unbind(ysd); @@ -680,7 +682,7 @@ #endif } - xdr_free(xdr_ypresp_val, (char *)&yprv); + xdr_free((xdrproc_t)xdr_ypresp_val, &yprv); return (r); } @@ -726,7 +728,8 @@ bzero((char *)&yprkv, sizeof yprkv); r = clnt_call(ysd->dom_client, YPPROC_FIRST, - xdr_ypreq_nokey, &yprnk, xdr_ypresp_key_val, &yprkv, tv); + (xdrproc_t)xdr_ypreq_nokey, &yprnk, + (xdrproc_t)xdr_ypresp_key_val, &yprkv, tv); if (r != RPC_SUCCESS) { clnt_perror(ysd->dom_client, "yp_first: clnt_call"); _yp_unbind(ysd); @@ -743,7 +746,7 @@ (*outval)[*outvallen] = '\0'; } - xdr_free(xdr_ypresp_key_val, (char *)&yprkv); + xdr_free((xdrproc_t)xdr_ypresp_key_val, &yprkv); return (r); } @@ -781,7 +784,8 @@ bzero((char *)&yprkv, sizeof yprkv); r = clnt_call(ysd->dom_client, YPPROC_NEXT, - xdr_ypreq_key, &yprk, xdr_ypresp_key_val, &yprkv, tv); + (xdrproc_t)xdr_ypreq_key, &yprk, + (xdrproc_t)xdr_ypresp_key_val, &yprkv, tv); if (r != RPC_SUCCESS) { clnt_perror(ysd->dom_client, "yp_next: clnt_call"); _yp_unbind(ysd); @@ -798,7 +802,7 @@ (*outval)[*outvallen] = '\0'; } - xdr_free(xdr_ypresp_key_val, (char *)&yprkv); + xdr_free((xdrproc_t)xdr_ypresp_key_val, &yprkv); return (r); } @@ -844,8 +848,8 @@ ypresp_data = (void *)incallback->data; if (clnt_call(clnt, YPPROC_ALL, - xdr_ypreq_nokey, &yprnk, - xdr_ypresp_all_seq, &status, tv) != RPC_SUCCESS) { + (xdrproc_t)xdr_ypreq_nokey, &yprnk, + (xdrproc_t)xdr_ypresp_all_seq, &status, tv) != RPC_SUCCESS) { clnt_perror(ysd->dom_client, "yp_all: clnt_call"); clnt_destroy(clnt); _yp_unbind(ysd); @@ -854,7 +858,7 @@ clnt_destroy(clnt); savstat = status; - xdr_free(xdr_ypresp_all_seq, (char *)&status); /* not really needed... */ + xdr_free((xdrproc_t)xdr_ypresp_all_seq, &status); /* not really needed... */ if (savstat != YP_NOMORE) return (ypprot_err(savstat)); return (0); @@ -888,7 +892,8 @@ bzero((char *)(char *)&ypro, sizeof ypro); r = clnt_call(ysd->dom_client, YPPROC_ORDER, - xdr_ypreq_nokey, &yprnk, xdr_ypresp_order, &ypro, tv); + (xdrproc_t)xdr_ypreq_nokey, &yprnk, + (xdrproc_t)xdr_ypresp_order, &ypro, tv); /* * NIS+ in YP compat mode doesn't support the YPPROC_ORDER @@ -908,7 +913,7 @@ *outorder = ypro.ordernum; } - xdr_free(xdr_ypresp_order, (char *)&ypro); + xdr_free((xdrproc_t)xdr_ypresp_order, &ypro); return (r); } @@ -939,7 +944,8 @@ bzero((char *)&yprm, sizeof yprm); r = clnt_call(ysd->dom_client, YPPROC_MASTER, - xdr_ypreq_nokey, &yprnk, xdr_ypresp_master, &yprm, tv); + (xdrproc_t)xdr_ypreq_nokey, &yprnk, + (xdrproc_t)xdr_ypresp_master, &yprm, tv); if (r != RPC_SUCCESS) { clnt_perror(ysd->dom_client, "yp_master: clnt_call"); _yp_unbind(ysd); @@ -950,7 +956,7 @@ *outname = (char *)strdup(yprm.peer); } - xdr_free(xdr_ypresp_master, (char *)&yprm); + xdr_free((xdrproc_t)xdr_ypresp_master, &yprm); return (r); } @@ -977,7 +983,8 @@ bzero((char *)&ypml, sizeof ypml); r = clnt_call(ysd->dom_client, YPPROC_MAPLIST, - xdr_domainname,(char *)&indomain,xdr_ypresp_maplist,&ypml,tv); + (xdrproc_t)xdr_domainname, &indomain, + (xdrproc_t)xdr_ypresp_maplist, &ypml,tv); if (r != RPC_SUCCESS) { clnt_perror(ysd->dom_client, "yp_maplist: clnt_call"); _yp_unbind(ysd); @@ -987,11 +994,11 @@ *outmaplist = ypml.maps; } - /* NO: xdr_free(xdr_ypresp_maplist, &ypml);*/ + /* NO: xdr_free((xdrproc_t)xdr_ypresp_maplist, &ypml);*/ return (r); } -char * +const char * yperr_string(int incode) { static char err[80]; ==== //depot/user/des/pam/libexec/rpc.rquotad/rquotad.c#3 (text+ko) ==== @@ -114,7 +114,7 @@ { switch (request->rq_proc) { case NULLPROC: - (void)svc_sendreply(transp, xdr_void, (char *)NULL); + (void)svc_sendreply(transp, (xdrproc_t)xdr_void, (char *)NULL); break; case RQUOTAPROC_GETQUOTA: @@ -140,7 +140,7 @@ struct timeval timev; bzero((char *)&getq_args, sizeof(getq_args)); - if (!svc_getargs(transp, xdr_getquota_args, (caddr_t)&getq_args)) { + if (!svc_getargs(transp, (xdrproc_t)xdr_getquota_args, &getq_args)) { svcerr_decode(transp); return; } @@ -172,10 +172,10 @@ getq_rslt.getquota_rslt_u.gqr_rquota.rq_ftimeleft = dqblk.dqb_itime - timev.tv_sec; } - if (!svc_sendreply(transp, xdr_getquota_rslt, (char *)&getq_rslt)) { + if (!svc_sendreply(transp, (xdrproc_t)xdr_getquota_rslt, &getq_rslt)) { svcerr_systemerr(transp); } - if (!svc_freeargs(transp, xdr_getquota_args, (caddr_t)&getq_args)) { + if (!svc_freeargs(transp, (xdrproc_t)xdr_getquota_args, &getq_args)) { syslog(LOG_ERR, "unable to free arguments"); exit(1); } @@ -273,7 +273,7 @@ * Convert implicit 0 quota (EOF) * into an explicit one (zero'ed dqblk) */ - bzero((caddr_t) dqblk, sizeof(struct dqblk)); + bzero(dqblk, sizeof(struct dqblk)); ret = 1; break; case sizeof(struct dqblk): /* OK */ ==== //depot/user/des/pam/libexec/rpc.rstatd/rstat_proc.c#3 (text+ko) ==== @@ -438,7 +438,7 @@ switch (rqstp->rq_proc) { case NULLPROC: - (void)svc_sendreply(transp, xdr_void, (char *)NULL); + (void)svc_sendreply(transp, (xdrproc_t)xdr_void, NULL); goto leave; case RSTATPROC_STATS: @@ -486,15 +486,16 @@ goto leave; } bzero((char *)&argument, sizeof(argument)); - if (!svc_getargs(transp, xdr_argument, (caddr_t)&argument)) { + if (!svc_getargs(transp, (xdrproc_t)xdr_argument, &argument)) { svcerr_decode(transp); goto leave; } result = (*local)(&argument, rqstp); - if (result != NULL && !svc_sendreply(transp, xdr_result, result)) { + if (result != NULL && + !svc_sendreply(transp, (xdrproc_t)xdr_result, result)) { svcerr_systemerr(transp); } - if (!svc_freeargs(transp, xdr_argument, (caddr_t)&argument)) + if (!svc_freeargs(transp, (xdrproc_t)xdr_argument, &argument)) errx(1, "unable to free arguments"); leave: if (from_inetd) ==== //depot/user/des/pam/libexec/rpc.rusersd/rusers_proc.c#3 (text+ko) ==== @@ -322,7 +322,7 @@ switch (rqstp->rq_proc) { case NULLPROC: - (void)svc_sendreply(transp, xdr_void, (char *)NULL); + (void)svc_sendreply(transp, (xdrproc_t)xdr_void, NULL); goto leave; case RUSERSPROC_NUM: @@ -369,16 +369,17 @@ svcerr_noproc(transp); goto leave; } - bzero((char *)&argument, sizeof(argument)); - if (!svc_getargs(transp, xdr_argument, (caddr_t)&argument)) { + bzero(&argument, sizeof(argument)); + if (!svc_getargs(transp, (xdrproc_t)xdr_argument, &argument)) { svcerr_decode(transp); goto leave; } result = (*local)(&argument, rqstp); - if (result != NULL && !svc_sendreply(transp, xdr_result, result)) { + if (result != NULL && + !svc_sendreply(transp, (xdrproc_t)xdr_result, result)) { svcerr_systemerr(transp); } - if (!svc_freeargs(transp, xdr_argument, (caddr_t)&argument)) { + if (!svc_freeargs(transp, (xdrproc_t)xdr_argument, &argument)) { syslog(LOG_ERR, "unable to free arguments"); exit(1); } ==== //depot/user/des/pam/libexec/rpc.rwalld/rwalld.c#4 (text+ko) ==== @@ -101,7 +101,7 @@ (void)pmap_unset(WALLPROG, WALLVERS); if ((s = socket(AF_INET, SOCK_DGRAM, IPPROTO_UDP)) < 0) err(1, "socket"); - bzero((char *)&sa, sizeof sa); + bzero(&sa, sizeof sa); if (bind(s, (struct sockaddr *)&sa, sizeof sa) < 0) err(1, "bind"); @@ -184,7 +184,7 @@ switch (rqstp->rq_proc) { case NULLPROC: - (void)svc_sendreply(transp, xdr_void, (char *)NULL); + (void)svc_sendreply(transp, (xdrproc_t)xdr_void, NULL); goto leave; case WALLPROC_WALL: @@ -197,16 +197,17 @@ svcerr_noproc(transp); goto leave; } - bzero((char *)&argument, sizeof(argument)); - if (!svc_getargs(transp, xdr_argument, (caddr_t)&argument)) { + bzero(&argument, sizeof(argument)); + if (!svc_getargs(transp, (xdrproc_t)xdr_argument, &argument)) { svcerr_decode(transp); goto leave; } result = (*local)(&argument, rqstp); - if (result != NULL && !svc_sendreply(transp, xdr_result, result)) { + if (result != NULL && + !svc_sendreply(transp, (xdrproc_t)xdr_result, result)) { svcerr_systemerr(transp); } - if (!svc_freeargs(transp, xdr_argument, (caddr_t)&argument)) { + if (!svc_freeargs(transp, (xdrproc_t)xdr_argument, &argument)) { syslog(LOG_ERR, "unable to free arguments"); exit(1); } ==== //depot/user/des/pam/libexec/rpc.sprayd/sprayd.c#3 (text+ko) ==== @@ -138,7 +138,7 @@ /*FALLTHROUGH*/ case NULLPROC: - (void)svc_sendreply(transp, xdr_void, (char *)NULL); + (void)svc_sendreply(transp, (xdrproc_t)xdr_void, NULL); return; case SPRAYPROC_SPRAY: @@ -157,7 +157,7 @@ return; } - if (!svc_sendreply(transp, xdr_spraycumul, (caddr_t)&scum)) { + if (!svc_sendreply(transp, (xdrproc_t)xdr_spraycumul, &scum)) { svcerr_systemerr(transp); syslog(LOG_ERR, "bad svc_sendreply"); } ==== //depot/user/des/pam/libexec/ypxfr/ypxfr_getmap.c#4 (text+ko) ==== @@ -84,8 +84,8 @@ ypresp_allfn = callback; ypresp_data = NULL; - (void)clnt_call(clnt, YPPROC_ALL, xdr_ypreq_nokey, &req, - xdr_ypresp_all_seq, &status, timeout); + (void)clnt_call(clnt, YPPROC_ALL, (xdrproc_t)xdr_ypreq_nokey, &req, + (xdrproc_t)xdr_ypresp_all_seq, &status, timeout); clnt_destroy(clnt); ==== //depot/user/des/pam/libexec/ypxfr/ypxfr_misc.c#5 (text+ko) ==== @@ -263,7 +263,7 @@ CLIENT *clnt; static char buf[YPMAXRECORD + 2]; - bzero((char *)buf, sizeof(buf)); + bzero(buf, sizeof(buf)); if ((clnt = clnt_create(server, YPPROG,YPVERS,"udp")) == NULL) { yp_error("failed to create UDP handle: %s", @@ -286,11 +286,11 @@ clnt_destroy(clnt); if (ypval->stat != YP_TRUE) { - xdr_free(xdr_ypresp_val, (char *)ypval); + xdr_free((xdrproc_t)xdr_ypresp_val, ypval); return(0); } - xdr_free(xdr_ypresp_val, (char *)ypval); + xdr_free((xdrproc_t)xdr_ypresp_val, ypval); return(1); } ==== //depot/user/des/pam/usr.sbin/keyserv/keyserv.c#3 (text+ko) ==== @@ -633,83 +633,83 @@ netobj key_get_conv_2_arg; } argument; char *result; - bool_t(*xdr_argument)(), (*xdr_result)(); + xdrproc_t xdr_argument, xdr_result; char *(*local) (); uid_t uid = -1; int check_auth; switch (rqstp->rq_proc) { case NULLPROC: - svc_sendreply(transp, xdr_void, (char *)NULL); + svc_sendreply(transp, (xdrproc_t)xdr_void, NULL); return; case KEY_SET: - xdr_argument = xdr_keybuf; - xdr_result = xdr_int; + xdr_argument = (xdrproc_t)xdr_keybuf; + xdr_result = (xdrproc_t)xdr_int; local = (char *(*)()) key_set_1_svc_prog; check_auth = 1; break; case KEY_ENCRYPT: - xdr_argument = xdr_cryptkeyarg; - xdr_result = xdr_cryptkeyres; + xdr_argument = (xdrproc_t)xdr_cryptkeyarg; + xdr_result = (xdrproc_t)xdr_cryptkeyres; local = (char *(*)()) key_encrypt_1_svc_prog; check_auth = 1; break; case KEY_DECRYPT: - xdr_argument = xdr_cryptkeyarg; - xdr_result = xdr_cryptkeyres; + xdr_argument = (xdrproc_t)xdr_cryptkeyarg; + xdr_result = (xdrproc_t)xdr_cryptkeyres; local = (char *(*)()) key_decrypt_1_svc_prog; check_auth = 1; break; case KEY_GEN: - xdr_argument = xdr_void; - xdr_result = xdr_des_block; + xdr_argument = (xdrproc_t)xdr_void; + xdr_result = (xdrproc_t)xdr_des_block; local = (char *(*)()) key_gen_1_svc_prog; check_auth = 0; break; case KEY_GETCRED: - xdr_argument = xdr_netnamestr; - xdr_result = xdr_getcredres; + xdr_argument = (xdrproc_t)xdr_netnamestr; + xdr_result = (xdrproc_t)xdr_getcredres; local = (char *(*)()) key_getcred_1_svc_prog; check_auth = 0; break; case KEY_ENCRYPT_PK: - xdr_argument = xdr_cryptkeyarg2; - xdr_result = xdr_cryptkeyres; + xdr_argument = (xdrproc_t)xdr_cryptkeyarg2; + xdr_result = (xdrproc_t)xdr_cryptkeyres; local = (char *(*)()) key_encrypt_pk_2_svc_prog; check_auth = 1; break; case KEY_DECRYPT_PK: - xdr_argument = xdr_cryptkeyarg2; - xdr_result = xdr_cryptkeyres; + xdr_argument = (xdrproc_t)xdr_cryptkeyarg2; + xdr_result = (xdrproc_t)xdr_cryptkeyres; local = (char *(*)()) key_decrypt_pk_2_svc_prog; check_auth = 1; break; case KEY_NET_PUT: - xdr_argument = xdr_key_netstarg; - xdr_result = xdr_keystatus; + xdr_argument = (xdrproc_t)xdr_key_netstarg; + xdr_result = (xdrproc_t)xdr_keystatus; local = (char *(*)()) key_net_put_2_svc_prog; check_auth = 1; break; case KEY_NET_GET: xdr_argument = (xdrproc_t) xdr_void; - xdr_result = xdr_key_netstres; + xdr_result = (xdrproc_t)xdr_key_netstres; local = (char *(*)()) key_net_get_2_svc_prog; check_auth = 1; break; case KEY_GET_CONV: xdr_argument = (xdrproc_t) xdr_keybuf; - xdr_result = xdr_cryptkeyres; + xdr_result = (xdrproc_t)xdr_cryptkeyres; local = (char *(*)()) key_get_conv_2_svc_prog; check_auth = 1; break; @@ -738,18 +738,18 @@ uid = ((struct authsys_parms *)rqstp->rq_clntcred)->aup_uid; } - memset((char *) &argument, 0, sizeof (argument)); - if (!svc_getargs(transp, xdr_argument, (caddr_t)&argument)) { + memset(&argument, 0, sizeof (argument)); + if (!svc_getargs(transp, xdr_argument, &argument)) { svcerr_decode(transp); return; } result = (*local) (uid, &argument); - if (!svc_sendreply(transp, xdr_result, (char *) result)) { + if (!svc_sendreply(transp, xdr_result, result)) { if (debugging) (void) fprintf(stderr, "unable to reply\n"); svcerr_systemerr(transp); } - if (!svc_freeargs(transp, xdr_argument, (caddr_t)&argument)) { + if (!svc_freeargs(transp, xdr_argument, &argument)) { if (debugging) (void) fprintf(stderr, "unable to free arguments\n"); ==== //depot/user/des/pam/usr.sbin/rpc.ypxfrd/ypxfrd_server.c#3 (text+ko) ==== @@ -103,7 +103,7 @@ snprintf (buf, sizeof(buf), "%s/%s/%s", yp_dir, argp->xfrdomain, argp->xfrmap); - if (access((char *)&buf, R_OK) == -1) { + if (access(buf, R_OK) == -1) { result.xfr_u.xfrstat = XFR_ACCESS; return(&result); } @@ -132,14 +132,14 @@ forked++; } #endif - if ((fp = open((char *)&buf, O_RDONLY)) == -1) { + if ((fp = open(buf, O_RDONLY)) == -1) { result.xfr_u.xfrstat = XFR_READ_ERR; return(&result); } /* Start sending the file. */ - svc_sendreply(rqstp->rq_xprt, xdr_my_xfr, (char *)&result); + svc_sendreply(rqstp->rq_xprt, (xdrproc_t)xdr_my_xfr, &result); close(fp); ==== //depot/user/des/pam/usr.sbin/spray/spray.c#2 (text+ko) ==== @@ -133,11 +133,12 @@ * The following (undocumented) hack resets the internal state * of the client handle. */ - clnt_control(cl, CLSET_TIMEOUT, (caddr_t)&NO_DEFAULT); + clnt_control(cl, CLSET_TIMEOUT, &NO_DEFAULT); /* Clear server statistics */ - if (clnt_call(cl, SPRAYPROC_CLEAR, xdr_void, NULL, xdr_void, NULL, TIMEOUT) != RPC_SUCCESS) + if (clnt_call(cl, SPRAYPROC_CLEAR, (xdrproc_t)xdr_void, NULL, + (xdrproc_t)xdr_void, NULL, TIMEOUT) != RPC_SUCCESS) errx(1, "%s", clnt_sperror(cl, NULL)); @@ -147,7 +148,8 @@ fflush (stdout); for (i = 0; i < count; i++) { - clnt_call(cl, SPRAYPROC_SPRAY, xdr_sprayarr, &host_array, xdr_void, NULL, ONE_WAY); + clnt_call(cl, SPRAYPROC_SPRAY, (xdrproc_t)xdr_sprayarr, + &host_array, (xdrproc_t)xdr_void, NULL, ONE_WAY); if (delay) { usleep(delay); @@ -156,7 +158,8 @@ /* Collect statistics from server */ - if (clnt_call(cl, SPRAYPROC_GET, xdr_void, NULL, xdr_spraycumul, &host_stats, TIMEOUT) != RPC_SUCCESS) + if (clnt_call(cl, SPRAYPROC_GET, (xdrproc_t)xdr_void, NULL, + (xdrproc_t)xdr_spraycumul, &host_stats, TIMEOUT) != RPC_SUCCESS) errx(1, "%s", clnt_sperror(cl, NULL)); xmit_time = host_stats.clock.sec + ==== //depot/user/des/pam/usr.sbin/yp_mkdb/yp_mkdb.c#3 (text+ko) ==== @@ -332,9 +332,9 @@ char in = 0; char *out = NULL; int stat; - if ((stat = callrpc("localhost",YPPROG,YPVERS,YPPROC_CLEAR, - xdr_void, (void *)&in, - xdr_void, (void *)out)) != RPC_SUCCESS) { + if ((stat = callrpc("localhost", YPPROG,YPVERS, YPPROC_CLEAR, + (xdrproc_t)xdr_void, &in, + (xdrproc_t)xdr_void, out)) != RPC_SUCCESS) { warnx("failed to send 'clear' to local ypserv: %s", clnt_sperrno((enum clnt_stat) stat)); } ==== //depot/user/des/pam/usr.sbin/ypbind/yp_ping.c#4 (text+ko) ==== @@ -147,8 +147,10 @@ parms.pm_vers = version; parms.pm_prot = protocol; parms.pm_port = 0; /* not needed or used */ - if (CLNT_CALL(client, PMAPPROC_GETPORT, xdr_pmap, &parms, - xdr_u_short, &port, tottimeout) != RPC_SUCCESS){ + if (CLNT_CALL(client, PMAPPROC_GETPORT, + (xdrproc_t)xdr_pmap, &parms, + (xdrproc_t)xdr_u_short, &port, + tottimeout) != RPC_SUCCESS){ rpc_createerr.cf_stat = RPC_PMAPFAILURE; clnt_geterr(client, &rpc_createerr.cf_error); } else if (port == 0) { ==== //depot/user/des/pam/usr.sbin/ypbind/ypbind.c#3 (text+ko) ==== @@ -160,8 +160,8 @@ { static char res; - bzero((char *)&res, sizeof(res)); - return (void *)&res; + bzero(&res, sizeof(res)); + return &res; } struct ypbind_resp * @@ -171,7 +171,7 @@ struct _dom_binding *ypdb; char path[MAXPATHLEN]; - bzero((char *)&res, sizeof res); + bzero(&res, sizeof res); res.ypbind_status = YPBIND_FAIL_VAL; res.ypbind_resp_u.ypbind_error = YPBIND_ERR_NOSERV; @@ -204,7 +204,7 @@ res.ypbind_resp_u.ypbind_error = YPBIND_ERR_RESC; return (&res); } - bzero((char *)ypdb, sizeof *ypdb); + bzero(ypdb, sizeof *ypdb); strncpy(ypdb->dom_domain, *argp, sizeof ypdb->dom_domain); ypdb->dom_vers = YPVERS; ypdb->dom_alive = 0; @@ -272,7 +272,7 @@ return(NULL); } - bzero((char *)&bindsin, sizeof bindsin); + bzero(&bindsin, sizeof bindsin); bindsin.sin_family = AF_INET; bindsin.sin_addr.s_addr = *(u_int32_t *)argp->ypsetdom_binding.ypbind_binding_addr; bindsin.sin_port = *(u_short *)argp->ypsetdom_binding.ypbind_binding_port; @@ -281,7 +281,7 @@ return((void *) &result); } -static void +void ypbindprog_2(struct svc_req *rqstp, register SVCXPRT *transp) { union { @@ -329,13 +329,14 @@ svcerr_noproc(transp); return; } - bzero((char *)&argument, sizeof(argument)); - if (!svc_getargs(transp, xdr_argument, (caddr_t)&argument)) { + bzero(&argument, sizeof(argument)); + if (!svc_getargs(transp, (xdrproc_t)xdr_argument, &argument)) { svcerr_decode(transp); return; } result = (*local)(transp, &argument, rqstp); - if (result != NULL && !svc_sendreply(transp, xdr_result, result)) { + if (result != NULL && + !svc_sendreply(transp, (xdrproc_t)xdr_result, result)) { svcerr_systemerr(transp); } return; @@ -449,7 +450,7 @@ ypbindlist = (struct _dom_binding *)malloc(sizeof *ypbindlist); if (ypbindlist == NULL) errx(1, "malloc"); - bzero((char *)ypbindlist, sizeof *ypbindlist); + bzero(ypbindlist, sizeof *ypbindlist); strncpy(ypbindlist->dom_domain, domain_name, sizeof ypbindlist->dom_domain); ypbindlist->dom_vers = YPVERS; ypbindlist->dom_alive = 0; @@ -540,7 +541,7 @@ FD_CLR(READFD, &svc_fdset); READFD = WRITEFD = -1; if (d > 0 && a > 0) - rpc_received((char *)&buf, &addr, 0); + rpc_received(buf, &addr, 0); else { for (y = ypbindlist; y; y = y->dom_pnext) { if (y == ypdb) @@ -615,7 +616,7 @@ struct sockaddr_in *addr; { if (retries >= MAX_RETRIES) { - bzero((char *)addr, sizeof(struct sockaddr_in)); + bzero(addr, sizeof(struct sockaddr_in)); if (tell_parent(broad_domain->dom_domain, addr)) syslog(LOG_WARNING, "lost connection to parent"); return (TRUE); @@ -704,15 +705,15 @@ i = __yp_ping(restricted_addrs, yp_restricted, ypdb->dom_domain, &port); if (i == -1) { - bzero((char *)&ypdb->dom_server_addr, - sizeof(struct sockaddr_in)); + bzero(&ypdb->dom_server_addr, + sizeof(struct sockaddr_in)); if (tell_parent(ypdb->dom_domain, - &ypdb->dom_server_addr)) + &ypdb->dom_server_addr)) syslog(LOG_WARNING, "lost connection to parent"); } else { - bzero((char *)&sin, sizeof(struct sockaddr_in)); - bcopy((char *)&restricted_addrs[i], - (char *)&sin.sin_addr, sizeof(struct in_addr)); + bzero(&sin, sizeof(struct sockaddr_in)); + bcopy(&restricted_addrs[i], + &sin.sin_addr, sizeof(struct in_addr)); sin.sin_family = AF_INET; sin.sin_port = port; if (tell_parent(broad_domain->dom_domain, &sin)) @@ -727,15 +728,16 @@ { char *ptr; - ptr = (char *)&ypdb->dom_domain; + ptr = ypdb->dom_domain; stat = clnt_broadcast(YPPROG, YPVERS, YPPROC_DOMAIN_NONACK, - xdr_domainname, (char *)&ptr, xdr_bool, (char *)&out, + (xdrproc_t)xdr_domainname, &ptr, + (xdrproc_t)xdr_bool, &out, (resultproc_t)broadcast_result); } if (stat != RPC_SUCCESS) { - bzero((char *)&ypdb->dom_server_addr, - sizeof(struct sockaddr_in)); + bzero(&ypdb->dom_server_addr, + sizeof(struct sockaddr_in)); if (tell_parent(ypdb->dom_domain, &ypdb->dom_server_addr)) syslog(LOG_WARNING, "lost connection to parent"); } @@ -785,11 +787,12 @@ { char *ptr; - ptr = (char *)&ypdb->dom_domain; + ptr = ypdb->dom_domain; - if ((stat = clnt_call(client_handle, YPPROC_DOMAIN, - xdr_domainname, (char *)&ptr, xdr_bool, (char *)&out, - timeout)) != RPC_SUCCESS || out == FALSE) { + stat = clnt_call(client_handle, YPPROC_DOMAIN, + (xdrproc_t)xdr_domainname, &ptr, + (xdrproc_t)xdr_bool, &out, timeout); + if (stat != RPC_SUCCESS || out == FALSE) { ypdb->dom_alive = 0; ypdb->dom_vers = -1; clnt_destroy(client_handle); @@ -877,7 +880,7 @@ syslog(LOG_WARNING, "malloc: %m"); return; } - bzero((char *)ypdb, sizeof *ypdb); + bzero(ypdb, sizeof *ypdb); strncpy(ypdb->dom_domain, dom, sizeof ypdb->dom_domain); ypdb->dom_lockfd = -1; ypdb->dom_default = 0; @@ -890,7 +893,7 @@ syslog(LOG_WARNING, "NIS server [%s] for domain \"%s\" OK", inet_ntoa(raddrp->sin_addr), ypdb->dom_domain); - bcopy((char *)raddrp, (char *)&ypdb->dom_server_addr, + bcopy(raddrp, &ypdb->dom_server_addr, sizeof ypdb->dom_server_addr); ypdb->dom_vers = YPVERS; @@ -923,9 +926,9 @@ */ ypdb->dom_lockfd = fd; - iov[0].iov_base = (caddr_t)&(udptransp->xp_port); + iov[0].iov_base = (char *)&(udptransp->xp_port); iov[0].iov_len = sizeof udptransp->xp_port; - iov[1].iov_base = (caddr_t)&ybr; + iov[1].iov_base = (char *)&ybr; iov[1].iov_len = sizeof ybr; bzero(&ybr, sizeof ybr); @@ -951,8 +954,7 @@ int i; for (i = 0; i < RESTRICTED_SERVERS; i++) - if (!bcmp((char *)&addr, (char *)&restricted_addrs[i], - sizeof(struct in_addr))) + if (!bcmp(&addr, &restricted_addrs[i], sizeof(struct in_addr))) return(0); return(1); @@ -978,9 +980,9 @@ while ((s = strsep(&args, ",")) != NULL && i < RESTRICTED_SERVERS) { if ((h = gethostbyname(s)) == NULL) return; - bcopy ((char *)h->h_addr_list[0], (char *)&restricted_addrs[i], - sizeof(struct in_addr)); - i++; + bcopy (h->h_addr_list[0], &restricted_addrs[i], + sizeof(struct in_addr)); + i++; } /* ypset and ypsetme not allowed with restricted mode */ ==== //depot/user/des/pam/usr.sbin/yppush/yppush_main.c#4 (text+ko) ==== @@ -508,7 +508,7 @@ } /* Cleared for takeoff: set everything in motion. */ - if (yp_push(&server, yppush_mapname, yppush_transid)) + if (yp_push(server, yppush_mapname, yppush_transid)) return(yp_errno); /* Bump the job counter and transaction ID. */ ==== //depot/user/des/pam/usr.sbin/ypserv/yp_dblookup.c#4 (text+ko) ==== @@ -318,7 +318,7 @@ * the same database comes in later. */ static DB * -yp_find_db(char *name, char *key, int size) +yp_find_db(const char *name, const char *key, int size) { register struct circleq_entry *qptr; @@ -364,11 +364,11 @@ strcat(buf, "/"); strcat(buf, map); - if ((dbp = yp_find_db((char *)&buf, key, size)) != NULL) { + if ((dbp = yp_find_db(buf, key, size)) != NULL) { return(dbp); } else { if ((dbp = yp_open_db(domain, map)) != NULL) { - if (yp_cache_db(dbp, (char *)&buf, size)) { + if (yp_cache_db(dbp, buf, size)) { (void)(dbp->close)(dbp); yp_errno = YP_YPERR; return(NULL); @@ -506,8 +506,8 @@ TAILQ_FIRST(&qhead)->dbptr->size = 0; } #else - bcopy((char *)data->data, (char *)&buf, data->size); - data->data = (void *)&buf; + bcopy(data->data, &buf, data->size); + data->data = &buf; (void)(dbp->close)(dbp); #endif @@ -558,8 +558,8 @@ TAILQ_FIRST(&qhead)->dbptr->size = key->size; } #else - bcopy((char *)data->data, (char *)&buf, data->size); - data->data = (void *)&buf; + bcopy(data->data, &buf, data->size); + data->data = &buf; #endif return(YP_TRUE); @@ -599,7 +599,7 @@ #endif (dbp->seq)(dbp,&lkey,&ldata,R_FIRST); while (key->size != lkey.size || - strncmp((char *)key->data, lkey.data, + strncmp(key->data, lkey.data, (int)key->size)) if ((dbp->seq)(dbp,&lkey,&ldata,R_NEXT)) { #ifdef DB_CACHE @@ -639,11 +639,11 @@ TAILQ_FIRST(&qhead)->dbptr->size = key->size; } #else - bcopy((char *)key->data, (char *)&keybuf, key->size); - lkey.data = (void *)&keybuf; + bcopy(key->data, &keybuf, key->size); + lkey.data = &keybuf; lkey.size = key->size; - bcopy((char *)data->data, (char *)&datbuf, data->size); - data->data = (void *)&datbuf; + bcopy(data->data, &datbuf, data->size); + data->data = &datbuf; #endif return(YP_TRUE); ==== //depot/user/des/pam/usr.sbin/ypserv/yp_server.c#3 (text+ko) ==== @@ -285,7 +285,7 @@ /* Turn the timeout off -- we don't want to block. */ timeout.tv_sec = 0; - if (clnt_control(clnt, CLSET_TIMEOUT, (char *)&timeout) == FALSE) + if (clnt_control(clnt, CLSET_TIMEOUT, &timeout) == FALSE) yp_error("failed to set timeout on ypproc_xfr callback"); if (yppushproc_xfrresp_1(&ypxfr_resp, clnt) == NULL) { @@ -303,7 +303,7 @@ #define YPXFR_RETURN(CODE) \ /* Order is important: send regular RPC reply, then callback */ \ result.xfrstat = CODE; \ - svc_sendreply(rqstp->rq_xprt, xdr_ypresp_xfr, (char *)&result); \ + svc_sendreply(rqstp->rq_xprt, (xdrproc_t)xdr_ypresp_xfr, &result); \ ypxfr_callback(CODE,rqhost,argp->transid, \ argp->prog,argp->port); \ return(NULL); @@ -378,7 +378,7 @@ "-p", yp_dir, "-C", t, g, inet_ntoa(rqhost->sin_addr), p, argp->map_parms.map, - (char *)NULL); + NULL); } else { execl(ypxfr_command, "ypxfr", "-d", argp->map_parms.domain, @@ -386,7 +386,7 @@ "-C", t, g, inet_ntoa(rqhost->sin_addr), p, argp->map_parms.map, - (char *)NULL); + NULL); } yp_error("ypxfr execl(%s): %s", ypxfr_command, strerror(errno)); YPXFR_RETURN(YPXFR_XFRERR) @@ -550,7 +550,7 @@ } /* Kick off the actual data transfer. */ - svc_sendreply(rqstp->rq_xprt, xdr_my_ypresp_all, (char *)&result); + svc_sendreply(rqstp->rq_xprt, (xdrproc_t)xdr_my_ypresp_all, &result); /* * Proper fix for PR #10970: exit here so that we don't risk @@ -598,10 +598,9 @@ */ result.stat = yp_getbykey(&key, &val); if (result.stat == YP_TRUE) { - bcopy((char *)val.valdat_val, (char *)&ypvalbuf, - val.valdat_len); + bcopy(val.valdat_val, &ypvalbuf, val.valdat_len); ypvalbuf[val.valdat_len] = '\0'; - result.peer = (char *)&ypvalbuf; + result.peer = ypvalbuf; } else result.peer = ""; @@ -646,7 +645,7 @@ result.stat = yp_getbykey(&key, &val); if (result.stat == YP_TRUE) - result.ordernum = atoi((char *)val.valdat_val); + result.ordernum = atoi(val.valdat_val); else result.ordernum = 0; @@ -698,7 +697,7 @@ yp_maplist_free(yp_maplist); return(NULL); } - if ((cur->map = (char *)strdup(dirp->d_name)) == NULL) { + if ((cur->map = strdup(dirp->d_name)) == NULL) { yp_error("strdup() failed: %s",strerror(errno)); closedir(dird); yp_maplist_free(yp_maplist); @@ -818,8 +817,7 @@ if (v2_result == NULL) return(NULL); - bcopy((char *)v2_result, - (char *)&result.ypresponse_u.yp_resp_valtype, + bcopy(v2_result, &result.ypresponse_u.yp_resp_valtype, sizeof(ypresp_val)); return (&result); @@ -850,8 +848,7 @@ if (v2_result == NULL) return(NULL); - bcopy((char *)v2_result, - (char *)&result.ypresponse_u.yp_resp_key_valtype, + bcopy(v2_result, &result.ypresponse_u.yp_resp_key_valtype, sizeof(ypresp_key_val)); return (&result); @@ -881,8 +878,7 @@ if (v2_result == NULL) return(NULL); - bcopy((char *)v2_result, - (char *)&result.ypresponse_u.yp_resp_key_valtype, + bcopy(v2_result, &result.ypresponse_u.yp_resp_key_valtype, sizeof(ypresp_key_val)); return (&result); ==== //depot/user/des/pam/usr.sbin/ypset/ypset.c#3 (text+ko) ==== @@ -100,7 +100,8 @@ client->cl_auth = authunix_create_default(); r = clnt_call(client, YPBINDPROC_SETDOM, - xdr_ypbind_setdom, &ypsd, xdr_void, NULL, tv); + (xdrproc_t)xdr_ypbind_setdom, &ypsd, + (xdrproc_t)xdr_void, NULL, tv); if (r) { warnx("sorry, cannot ypset for domain %s on host", dom); clnt_destroy(client); --=-=-=-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Apr 26 2: 1: 5 2002 Delivered-To: freebsd-arch@freebsd.org Received: from kayak.xcllnt.net (209-128-86-226.bayarea.net [209.128.86.226]) by hub.freebsd.org (Postfix) with ESMTP id A448037B405 for ; Fri, 26 Apr 2002 02:00:57 -0700 (PDT) Received: from athlon.pn.xcllnt.net (athlon.pn.xcllnt.net [192.168.4.3]) by kayak.xcllnt.net (8.11.6/8.11.4) with ESMTP id g3Q90vJ75008 for ; Fri, 26 Apr 2002 02:00:57 -0700 (PDT) (envelope-from marcel@kayak.pn.xcllnt.net) Received: from athlon.pn.xcllnt.net (localhost [127.0.0.1]) by athlon.pn.xcllnt.net (8.12.3/8.12.2) with ESMTP id g3Q90v2D043464 for ; Fri, 26 Apr 2002 02:00:57 -0700 (PDT) (envelope-from marcel@athlon.pn.xcllnt.net) Received: (from marcel@localhost) by athlon.pn.xcllnt.net (8.12.3/8.12.3/Submit) id g3Q90uAP043463 for arch@FreeBSD.org; Fri, 26 Apr 2002 02:00:56 -0700 (PDT) Date: Fri, 26 Apr 2002 02:00:56 -0700 From: Marcel Moolenaar To: arch@FreeBSD.org Subject: RTLD fix: part 2: ld-elf.so Message-ID: <20020426090056.GA43410@athlon.pn.xcllnt.net> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="qDbXVdCdHGoSgWSk" Content-Disposition: inline User-Agent: Mutt/1.3.27i Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG --qDbXVdCdHGoSgWSk Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Gang, Part 2 of the RTLD fix. Tested on: alpha, ia64 Compiles on: i386 Please review, -- Marcel Moolenaar USPA: A-39004 marcel@xcllnt.net --qDbXVdCdHGoSgWSk Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="rtld.diff" Index: rtld.c =================================================================== RCS file: /home/ncvs/src/libexec/rtld-elf/rtld.c,v retrieving revision 1.63 diff -u -r1.63 rtld.c --- rtld.c 2 Apr 2002 02:19:02 -0000 1.63 +++ rtld.c 26 Apr 2002 08:52:02 -0000 @@ -854,20 +854,27 @@ ref = refobj->symtab + symnum; name = refobj->strtab + ref->st_name; - hash = elf_hash(name); defobj = NULL; - /* Handle STT_SECTION specially. */ - if (ELF_ST_TYPE(ref->st_info) == STT_SECTION) { - if (ELF_ST_BIND(ref->st_info) != STB_LOCAL || - ref->st_shndx != symnum) { + /* + * We don't have to do a full scale lookup if the symbol is local. + * We know it will bind to the instance in this load module; to + * which we already have a pointer (ie ref). By not doing a lookup, + * we not only improve performance, but it also avoids unresolvable + * symbols when local symbols are not in the hash table. This has + * been seen with the ia64 toolchain. + */ + if (ELF_ST_BIND(ref->st_info) != STB_LOCAL) { + if (ELF_ST_TYPE(ref->st_info) == STT_SECTION) { _rtld_error("%s: Bogus symbol table entry %lu", refobj->path, symnum); } + hash = elf_hash(name); + def = symlook_default(name, hash, refobj, &defobj, in_plt); + } else { def = ref; defobj = refobj; - } else - def = symlook_default(name, hash, refobj, &defobj, in_plt); + } /* * If we found no definition and the reference is weak, treat the --qDbXVdCdHGoSgWSk-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Apr 26 4: 7:43 2002 Delivered-To: freebsd-arch@freebsd.org Received: from areilly.bpc-users.org (CPE-144-132-240-160.nsw.bigpond.net.au [144.132.240.160]) by hub.freebsd.org (Postfix) with SMTP id 8EA7937B41C for ; Fri, 26 Apr 2002 04:07:33 -0700 (PDT) Received: (qmail 26366 invoked from network); 26 Apr 2002 11:07:33 -0000 Received: from localhost (andrew@127.0.0.1) by localhost with SMTP; 26 Apr 2002 11:07:33 -0000 Subject: Re: diff & patch problem with 'No newline' From: Andrew Reilly To: Garance A Drosihn Cc: Mike Barcroft , arch@FreeBSD.ORG, "M. Warner Losh" , freebsd-standards@FreeBSD.ORG In-Reply-To: References: <200202091752.g19HqFP11551@green.bikeshed.org> <20020210040158.A26957@chiark.greenend.org.uk> <20020425210035.A43192@espresso.q9media.com> Content-Type: text/plain Content-Transfer-Encoding: 7bit X-Mailer: Ximian Evolution 1.0.3 Date: 26 Apr 2002 21:07:32 +1000 Message-Id: <1019819253.450.389.camel@gurney.reilly.home> Mime-Version: 1.0 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Fri, 2002-04-26 at 14:12, Garance A Drosihn wrote: > So, that's my pitch. I feel fairly strongly that there is a > real advantage in following the lead of Linux (+anyone using > gnu-diff) and NetBSD in this matter. How strongly do others > feel that we should stick to the letter of this standard, > because they feel the standard really has the right idea? > > And if you feel that way, then could you please explain to me > what the advantage is? Can you come up with any tangible > benefit of the standard which would convince a linux user to > give up this non-standard extension which they have been > using for at least five years? I know that you didn't ask for it, but I'd like to voice a strong vote of "yea" for (at least) teaching our patch to handle the "\no new line" in diffs. I don't any more (my MB cap has been raised), but I used to follow the wine port by rolling my own tarballs after patching with the incremental patches that they posted on their ftp site. These were _huge_ patch files, and almost always contained some "\no new line" lines, that our patch would not DTRT with. I don't care whether our diff produces those lines one way or the other. I use vi. It doesn't believe in files without newlines at the end. -- Andrew To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Apr 26 8:50:47 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mail.rpi.edu (mail.rpi.edu [128.113.22.40]) by hub.freebsd.org (Postfix) with ESMTP id 95A1D37B41F; Fri, 26 Apr 2002 08:50:43 -0700 (PDT) Received: from [128.113.24.47] (gilead.netel.rpi.edu [128.113.24.47]) by mail.rpi.edu (8.12.1/8.12.1) with ESMTP id g3QFoHp8533702; Fri, 26 Apr 2002 11:50:17 -0400 Mime-Version: 1.0 X-Sender: drosih@mail.rpi.edu Message-Id: In-Reply-To: <1019819253.450.389.camel@gurney.reilly.home> References: <200202091752.g19HqFP11551@green.bikeshed.org> <20020210040158.A26957@chiark.greenend.org.uk> <20020425210035.A43192@espresso.q9media.com> <1019819253.450.389.camel@gurney.reilly.home> Date: Fri, 26 Apr 2002 11:50:16 -0400 To: Andrew Reilly From: Garance A Drosihn Subject: Re: diff & patch problem with 'No newline' Cc: arch@FreeBSD.ORG, freebsd-standards@FreeBSD.ORG Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.3 (www dot roaringpenguin dot com slash mimedefang) Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG At 9:07 PM +1000 4/26/02, Andrew Reilly wrote: >On Fri, 2002-04-26 at 14:12, Garance A Drosihn wrote: >> So, that's my pitch. I feel fairly strongly that there is a >> real advantage in following the lead of Linux (+anyone using > > gnu-diff) and NetBSD in this matter. > >I know that you didn't ask for it, but I'd like to voice a >strong vote of "yea" for (at least) teaching our patch to >handle the "\no new line" in diffs. I'm willing to ask for any votes of "yea". It's the votes of "nay" that I'm not asking for... :-) :-) -- Garance Alistair Drosehn = gad@gilead.netel.rpi.edu Senior Systems Programmer or gad@freebsd.org Rensselaer Polytechnic Institute or drosih@rpi.edu To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Apr 26 9: 0:21 2002 Delivered-To: freebsd-arch@freebsd.org Received: from rover.village.org (rover.bsdimp.com [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id 4C07837B41C; Fri, 26 Apr 2002 09:00:10 -0700 (PDT) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.11.3/8.11.3) with ESMTP id g3QG08H96928; Fri, 26 Apr 2002 10:00:08 -0600 (MDT) (envelope-from imp@village.org) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.11.6/8.11.6) with ESMTP id g3QG07b48822; Fri, 26 Apr 2002 10:00:07 -0600 (MDT) (envelope-from imp@village.org) Date: Fri, 26 Apr 2002 09:59:55 -0600 (MDT) Message-Id: <20020426.095955.80136029.imp@village.org> To: drosih@rpi.edu Cc: areilly@bigpond.net.au, arch@FreeBSD.ORG, freebsd-standards@FreeBSD.ORG Subject: Re: diff & patch problem with 'No newline' From: "M. Warner Losh" In-Reply-To: References: <1019819253.450.389.camel@gurney.reilly.home> X-Mailer: Mew version 2.1 on Emacs 21.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In message: Garance A Drosihn writes: : At 9:07 PM +1000 4/26/02, Andrew Reilly wrote: : >On Fri, 2002-04-26 at 14:12, Garance A Drosihn wrote: : >> So, that's my pitch. I feel fairly strongly that there is a : >> real advantage in following the lead of Linux (+anyone using : > > gnu-diff) and NetBSD in this matter. : > : >I know that you didn't ask for it, but I'd like to voice a : >strong vote of "yea" for (at least) teaching our patch to : >handle the "\no new line" in diffs. : : I'm willing to ask for any votes of "yea". It's the votes : of "nay" that I'm not asking for... :-) :-) My plans had always been to back out Green's change (with Green's permission, btw) when there was a patch that could grok things. The back out wouldn't be MFC'd until after at least one release. Since this was historical FreeBSD behavior, and modern patches grok the end of line things, I see this as a no brainer: just do it once patch is patched :-) Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Apr 26 13:19:39 2002 Delivered-To: freebsd-arch@freebsd.org Received: from green.bikeshed.org (freefall.FreeBSD.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id 88E9737B419; Fri, 26 Apr 2002 13:19:30 -0700 (PDT) Received: from localhost (green@localhost) by green.bikeshed.org (8.11.6/8.11.6) with ESMTP id g3QKJSs87524; Fri, 26 Apr 2002 16:19:29 -0400 (EDT) (envelope-from green@green.bikeshed.org) Message-Id: <200204262019.g3QKJSs87524@green.bikeshed.org> X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: "M. Warner Losh" Cc: drosih@rpi.edu, areilly@bigpond.net.au, arch@FreeBSD.ORG, freebsd-standards@FreeBSD.ORG Subject: Re: diff & patch problem with 'No newline' In-Reply-To: Your message of "Fri, 26 Apr 2002 09:59:55 MDT." <20020426.095955.80136029.imp@village.org> From: "Brian F. Feldman" Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 26 Apr 2002 16:19:28 -0400 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG "M. Warner Losh" wrote: > In message: > Garance A Drosihn writes: > : At 9:07 PM +1000 4/26/02, Andrew Reilly wrote: > : >On Fri, 2002-04-26 at 14:12, Garance A Drosihn wrote: > : >> So, that's my pitch. I feel fairly strongly that there is a > : >> real advantage in following the lead of Linux (+anyone using > : > > gnu-diff) and NetBSD in this matter. > : > > : >I know that you didn't ask for it, but I'd like to voice a > : >strong vote of "yea" for (at least) teaching our patch to > : >handle the "\no new line" in diffs. > : > : I'm willing to ask for any votes of "yea". It's the votes > : of "nay" that I'm not asking for... :-) :-) > > My plans had always been to back out Green's change (with Green's > permission, btw) when there was a patch that could grok things. The > back out wouldn't be MFC'd until after at least one release. Since > this was historical FreeBSD behavior, and modern patches grok the end > of line things, I see this as a no brainer: just do it once patch is > patched :-) So, as a solution for unbreaking old machines which won't understand what to do with those patch files (as largely demonstrated by the ports, of course), should there be a port for a "new" version of patch which the ports system can depend upon and use instead of the base system's patch? I can see this mattering because people are very comfortable running releases from several years ago. -- Brian Fundakowski Feldman \'[ FreeBSD ]''''''''''\ <> green@FreeBSD.org <> bfeldman@tislabs.com \ The Power to Serve! \ Opinions expressed are my own. \,,,,,,,,,,,,,,,,,,,,,,\ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Apr 26 13:23:12 2002 Delivered-To: freebsd-arch@freebsd.org Received: from rover.village.org (rover.bsdimp.com [204.144.255.66]) by hub.freebsd.org (Postfix) with ESMTP id DA5EA37B419; Fri, 26 Apr 2002 13:22:59 -0700 (PDT) Received: from harmony.village.org (harmony.village.org [10.0.0.6]) by rover.village.org (8.11.3/8.11.3) with ESMTP id g3QKMwH98274; Fri, 26 Apr 2002 14:22:58 -0600 (MDT) (envelope-from imp@village.org) Received: from localhost (warner@rover2.village.org [10.0.0.1]) by harmony.village.org (8.11.6/8.11.6) with ESMTP id g3QKMvb50647; Fri, 26 Apr 2002 14:22:57 -0600 (MDT) (envelope-from imp@village.org) Date: Fri, 26 Apr 2002 14:22:52 -0600 (MDT) Message-Id: <20020426.142252.15670459.imp@village.org> To: green@FreeBSD.ORG Cc: drosih@rpi.edu, areilly@bigpond.net.au, arch@FreeBSD.ORG, freebsd-standards@FreeBSD.ORG Subject: Re: diff & patch problem with 'No newline' From: "M. Warner Losh" In-Reply-To: <200204262019.g3QKJSs87524@green.bikeshed.org> References: <20020426.095955.80136029.imp@village.org> <200204262019.g3QKJSs87524@green.bikeshed.org> X-Mailer: Mew version 2.1 on Emacs 21.1 / Mule 5.0 (SAKAKI) Mime-Version: 1.0 Content-Type: Text/Plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG In message: <200204262019.g3QKJSs87524@green.bikeshed.org> "Brian F. Feldman" writes: : So, as a solution for unbreaking old machines which won't understand what to : do with those patch files (as largely demonstrated by the ports, of course), : should there be a port for a "new" version of patch which the ports system : can depend upon and use instead of the base system's patch? I can see this : mattering because people are very comfortable running releases from several : years ago. That's a problem for ports people to deal with :-) They routinely have stuff like this. I think we should MFC the patch changes for 4.6, but wait for the diff changes for 4.7 so that we have a patch that can grok the stuff for at least three months before we have a diff in -stable that will generate them. Warner To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Apr 26 13:34:56 2002 Delivered-To: freebsd-arch@freebsd.org Received: from green.bikeshed.org (freefall.FreeBSD.org [216.136.204.21]) by hub.freebsd.org (Postfix) with ESMTP id 0019737B417; Fri, 26 Apr 2002 13:34:50 -0700 (PDT) Received: from localhost (green@localhost) by green.bikeshed.org (8.11.6/8.11.6) with ESMTP id g3QKYow87624; Fri, 26 Apr 2002 16:34:50 -0400 (EDT) (envelope-from green@green.bikeshed.org) Message-Id: <200204262034.g3QKYow87624@green.bikeshed.org> X-Mailer: exmh version 2.5 07/13/2001 with nmh-1.0.4 To: "M. Warner Losh" Cc: drosih@rpi.edu, areilly@bigpond.net.au, arch@FreeBSD.ORG, freebsd-standards@FreeBSD.ORG Subject: Re: diff & patch problem with 'No newline' In-Reply-To: Your message of "Fri, 26 Apr 2002 14:22:52 MDT." <20020426.142252.15670459.imp@village.org> From: "Brian F. Feldman" Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Date: Fri, 26 Apr 2002 16:34:50 -0400 Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG "M. Warner Losh" wrote: > In message: <200204262019.g3QKJSs87524@green.bikeshed.org> > "Brian F. Feldman" writes: > : So, as a solution for unbreaking old machines which won't understand what to > : do with those patch files (as largely demonstrated by the ports, of course), > : should there be a port for a "new" version of patch which the ports system > : can depend upon and use instead of the base system's patch? I can see this > : mattering because people are very comfortable running releases from several > : years ago. > > That's a problem for ports people to deal with :-) They routinely > have stuff like this. > > I think we should MFC the patch changes for 4.6, but wait for the diff > changes for 4.7 so that we have a patch that can grok the stuff for at > least three months before we have a diff in -stable that will generate > them. Okay, I didn't know if the plans changed to being to update both patch and diff at the same time before 4.6! Since they didn't, I remain happified. -- Brian Fundakowski Feldman \'[ FreeBSD ]''''''''''\ <> green@FreeBSD.org <> bfeldman@tislabs.com \ The Power to Serve! \ Opinions expressed are my own. \,,,,,,,,,,,,,,,,,,,,,,\ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Fri Apr 26 13:36: 2 2002 Delivered-To: freebsd-arch@freebsd.org Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by hub.freebsd.org (Postfix) with ESMTP id 65EF337B404; Fri, 26 Apr 2002 13:35:59 -0700 (PDT) Received: by elvis.mu.org (Postfix, from userid 1192) id 34443AE165; Fri, 26 Apr 2002 13:35:59 -0700 (PDT) Date: Fri, 26 Apr 2002 13:35:59 -0700 From: Alfred Perlstein To: "Brian F. Feldman" Cc: "M. Warner Losh" , drosih@rpi.edu, areilly@bigpond.net.au, arch@FreeBSD.ORG, freebsd-standards@FreeBSD.ORG Subject: Re: diff & patch problem with 'No newline' Message-ID: <20020426203559.GK1530@elvis.mu.org> References: <20020426.095955.80136029.imp@village.org> <200204262019.g3QKJSs87524@green.bikeshed.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <200204262019.g3QKJSs87524@green.bikeshed.org> User-Agent: Mutt/1.3.27i Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG * Brian F. Feldman [020426 13:19] wrote: > > So, as a solution for unbreaking old machines which won't understand what to > do with those patch files (as largely demonstrated by the ports, of course), > should there be a port for a "new" version of patch which the ports system > can depend upon and use instead of the base system's patch? I can see this > mattering because people are very comfortable running releases from several > years ago. I think the way bzip2 is handled might work. -- -Alfred Perlstein [alfred@freebsd.org] 'Instead of asking why a piece of software is using "1970s technology," start asking why software is ignoring 30 years of accumulated wisdom.' Tax deductible donations for FreeBSD: http://www.freebsdfoundation.org/ To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Apr 27 19:24:26 2002 Delivered-To: freebsd-arch@freebsd.org Received: from numeri.campus.luth.se (numeri.campus.luth.se [130.240.197.103]) by hub.freebsd.org (Postfix) with ESMTP id B2FE837B404 for ; Sat, 27 Apr 2002 19:24:18 -0700 (PDT) Received: (from k@localhost) by numeri.campus.luth.se (8.11.6/8.11.6) id g3S2OHo47643 for freebsd-arch@freebsd.org; Sun, 28 Apr 2002 04:24:17 +0200 (CEST) (envelope-from k) Date: Sun, 28 Apr 2002 04:24:17 +0200 From: Johan Karlsson To: freebsd-arch@freebsd.org Subject: NOSUID and NOSUID_LIST make knobs Message-ID: <20020428042417.A15611@numeri.campus.luth.se> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="d6Gm4EdcadzBjdND" Content-Disposition: inline User-Agent: Mutt/1.2.5i Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG --d6Gm4EdcadzBjdND Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Hi I have now tried to make a scalable easy maintained version of my prev proposition. This version uses the NOSUID_LIST proposal from Peter and is handled in bsd.prog.mk instead of the individual Makefiles. Basicaly it removes the suid bit if either NOSUID is defined or if PROG is in NOSUID_LIST (similar for sgid). I could not get ${NOSUID_LIST:M${PROG}} to work and solved it using a for loop instead. I could only get something like ${NOSUID_LIST:Mchpass} to work but then the stuff would have to be in the Makefile for the program. Please review the new version and send me comment and suggestions for improvement. I have tested this patch with buildworld/installworld. /Johan K -- Johan Karlsson mailto:k@numeri.campus.luth.se --d6Gm4EdcadzBjdND Content-Type: text/plain; charset=us-ascii Content-Disposition: attachment; filename="NOSUID.diff" Index: Makefile.inc1 =================================================================== RCS file: /home/ncvs/src/Makefile.inc1,v retrieving revision 1.261 diff -u -r1.261 Makefile.inc1 --- Makefile.inc1 2002/04/26 17:55:10 1.261 +++ Makefile.inc1 2002/04/28 02:03:19 @@ -355,9 +355,9 @@ # installworld: installcheck mkdir -p ${INSTALLTMP} - for prog in [ awk cat chflags chmod chown date echo egrep find grep \ - ln make makewhatis mkdir mtree mv perl rm sed sh sysctl \ - test true uname wc zic; do \ + for prog in [ awk cat chflags chmod chown date echo egrep expr \ + find grep ln make makewhatis mkdir mtree mv perl rm sed sh \ + sysctl test true uname wc zic; do \ cp `which $$prog` ${INSTALLTMP}; \ done cd ${.CURDIR}; ${IMAKE} reinstall Index: share/examples/etc/make.conf =================================================================== RCS file: /home/ncvs/src/share/examples/etc/make.conf,v retrieving revision 1.186 diff -u -r1.186 make.conf --- share/examples/etc/make.conf 2002/04/23 23:59:51 1.186 +++ share/examples/etc/make.conf 2002/04/28 02:03:25 @@ -88,6 +88,31 @@ # To enable installing ssh(1) with the setuid bit turned on #ENABLE_SUID_SSH= true # +# To avoid installing any program with the setuid/setgid bit turned on +#NOSUID= true +#NOSGID= true +# +# To avoid installing some programs with the setuid/setgid bit turned on +#NOSUID_LIST= rcp # /bin +#NOSUID_LIST+= ping ping6 shutdown # /sbin +#NOSUID_LIST+= at atq atrm batch # /usr/bin +#NOSUID_LIST+= chpass chfn chsh crontab +#NOSUID_LIST+= lock login +#NOSUID_LIST+= lpq lpr lprm +#NOSUID_LIST+= opieinfo opiepasswd passwd +#NOSUID_LIST+= quota rlogin rsh su +#NOSUID_LIST+= ypchpass ypchfn ypchsh yppasswd +#NOSUID_LIST+= mrinfo mtrace ppp pppd # /usr/sbin +#NOSUID_LIST+= sliplogin timedc +#NOSUID_LIST+= traceroute traceroute6 +#NOSUID_LIST+= k5su # kerberos5 +# +#NOSGID_LIST= fstat lpq lpr lprm netstat # /usr/bin +#NOSGID_LIST+= vmstat wall write +#NOSGID_LIST+= dm # /usr/games +#NOSGID_LIST+= sendmail # /usr/libexec/sendmail +#NOSGID_LIST+= lpc pstat swapinfo trpt # /usr/sbin +# # To avoid building various parts of the base system: #NO_CVS= true # do not build CVS #NO_CXX= true # do not build C++ and friends Index: share/man/man5/make.conf.5 =================================================================== RCS file: /home/ncvs/src/share/man/man5/make.conf.5,v retrieving revision 1.43 diff -u -r1.43 make.conf.5 --- share/man/man5/make.conf.5 2002/04/23 23:59:51 1.43 +++ share/man/man5/make.conf.5 2002/04/28 02:03:27 @@ -480,11 +480,23 @@ set to not build crypto code in .Pa secure subdir. +.It Va NOSGID +.Pq Vt bool +Set to disable the installation of any program with the setgid bit set. +.It Va NOSGID_LIST +.Pq Vt str +List of programs for which to disable the installation with the setgid bit set. .It Va NOSHARE .Pq Vt bool Set to not build in the .Pa share subdir. +.It Va NOSUID +.Pq Vt bool +Set to disable the installation of any program with the setuid bit set. +.It Va NOSUID_LIST +.Pq Vt str +List of programs for which to disable the installation with the setuid bit set. .It Va NOUUCP .Pq Vt bool Set to not build Index: share/mk/bsd.prog.mk =================================================================== RCS file: /home/ncvs/src/share/mk/bsd.prog.mk,v retrieving revision 1.116 diff -u -r1.116 bsd.prog.mk --- share/mk/bsd.prog.mk 2002/04/24 13:29:34 1.116 +++ share/mk/bsd.prog.mk 2002/04/28 02:03:28 @@ -103,15 +103,43 @@ _INSTALLFLAGS:= ${_INSTALLFLAGS${ie}} .endfor +# Remove the suid bit if set and +# ${PROG} is in ${NOSUID_LIST} or ${NOSUID} is defined. +_BINMODE = ${BINMODE} +.if ${BINMODE} > 4000 +.for __T in ${NOSUID_LIST} +.if ${PROG}==${__T} +NOSUID?= true +.endif +.endfor +.if defined(NOSUID) +_BINMODE!=expr ${BINMODE} - 4000 +.endif +.endif + +# Remove the sgid bit if set and +# ${PROG} is in ${NOSGID_LIST} or ${NOSGID} is defined. +__BINMODE=${_BINMODE} +.if ${_BINMODE} > 6000 || ${_BINMODE} < 4000 && ${_BINMODE} > 2000 +.for __T in ${NOSGID_LIST} +.if ${PROG}==${__T} +NOSGID?= true +.endif +.endfor +.if defined(NOSGID) +__BINMODE!=expr ${_BINMODE} - 2000 +.endif +.endif + realinstall: beforeinstall realinstall: _proginstall _proginstall: .if defined(PROG) .if defined(PROGNAME) - ${INSTALL} ${COPY} ${STRIP} -o ${BINOWN} -g ${BINGRP} -m ${BINMODE} \ + ${INSTALL} ${COPY} ${STRIP} -o ${BINOWN} -g ${BINGRP} -m ${__BINMODE} \ ${_INSTALLFLAGS} ${PROG} ${DESTDIR}${BINDIR}/${PROGNAME} .else - ${INSTALL} ${COPY} ${STRIP} -o ${BINOWN} -g ${BINGRP} -m ${BINMODE} \ + ${INSTALL} ${COPY} ${STRIP} -o ${BINOWN} -g ${BINGRP} -m ${__BINMODE} \ ${_INSTALLFLAGS} ${PROG} ${DESTDIR}${BINDIR} .endif .endif --d6Gm4EdcadzBjdND-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Apr 27 19:30:31 2002 Delivered-To: freebsd-arch@freebsd.org Received: from mail.rpi.edu (mail.rpi.edu [128.113.22.40]) by hub.freebsd.org (Postfix) with ESMTP id E1F4F37B404 for ; Sat, 27 Apr 2002 19:30:27 -0700 (PDT) Received: from [128.113.24.47] (gilead.netel.rpi.edu [128.113.24.47]) by mail.rpi.edu (8.12.1/8.12.1) with ESMTP id g3S2UQjJ542912 for ; Sat, 27 Apr 2002 22:30:26 -0400 Mime-Version: 1.0 X-Sender: drosih@mail.rpi.edu Message-Id: Date: Sat, 27 Apr 2002 22:30:25 -0400 To: arch@FreeBSD.ORG From: Garance A Drosihn Subject: Thinking about more work on 'patch' Content-Type: text/plain; charset="us-ascii" ; format="flowed" X-Scanned-By: MIMEDefang 2.3 (www dot roaringpenguin dot com slash mimedefang) Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG When checking the 'patch' utility while doing the "no newline" update, I noticed that both OpenBSD and NetBSD have a number of nice updates to clean up parts of the source code. I also noticed that both of them have a version of patch which is BSD-licensed, apparently because someone got Larry Wall to re-license one of the early versions of patch [I am a little vague on the exact details there...]. FreeBSD has the following versions of patch in the src tree: src/usr.bin/patch (entirely moved into the attic) src/gnu/usr.bin/patch (what we are actually using as /usr/bin/patch, it is based on patch 2.1) src/contrib/patch (an attempt to bring in a more recent version of gnu-patch, namely, version 2.5). What I'd like to do is something like: Take the patch from OpenBSD or NetBSD, and put it in src/usr.bin (I think theirs are based on patch 2.0.). Then add whatever updates the other one has done, and then add whatever updates we (as freebsd) have done. The idea is to end up with a bsd-licensed version which has all the stuff we're used to, along with all of the cleanup changes done by NetBSD and OpenBSD. I could also glance at patch 2.5 and see if there's any particularly attractive options than it has, and re-implement them (not "copy & paste them", but rewrite the options to keep a BSD license). I am in no rush to do this, but does this seem like a worthwhile thing to do? I would not want to commit anything to src/usr.bin/patch until I had a pretty good start on the work, but on the other hand I don't want to start on the work if no one would want the end result... Initially I'd suggest putting it in with 'PROG=bpatch' in the Makefile (just so it will not install over the patch we presently use), and only switch it to being 'patch' when we are comfortable that I have all the pieces in the new version. Once done, we could then toss both of the other two versions into the attic. Is this worth doing? -- Garance Alistair Drosehn = gad@gilead.netel.rpi.edu Senior Systems Programmer or gad@freebsd.org Rensselaer Polytechnic Institute or drosih@rpi.edu To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Apr 27 20:51:32 2002 Delivered-To: freebsd-arch@freebsd.org Received: from elvis.mu.org (elvis.mu.org [192.203.228.196]) by hub.freebsd.org (Postfix) with ESMTP id 2002337B416 for ; Sat, 27 Apr 2002 20:51:30 -0700 (PDT) Received: by elvis.mu.org (Postfix, from userid 1192) id E04FBAE162; Sat, 27 Apr 2002 20:51:29 -0700 (PDT) Date: Sat, 27 Apr 2002 20:51:29 -0700 From: Alfred Perlstein To: Garance A Drosihn Cc: arch@FreeBSD.ORG Subject: Re: Thinking about more work on 'patch' Message-ID: <20020428035129.GS1530@elvis.mu.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.3.27i Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG * Garance A Drosihn [020427 19:30] wrote: > > Once done, we could then toss both of the other two versions > into the attic. Is this worth doing? I think it's a worthwhile task, the more truly free code in the base, the better off we are. Thanks for taking the time to look into this and offering to do it, it would really be a nice thing to see done. -Alfred To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message From owner-freebsd-arch Sat Apr 27 21:49: 5 2002 Delivered-To: freebsd-arch@freebsd.org Received: from rwcrmhc51.attbi.com (rwcrmhc51.attbi.com [204.127.198.38]) by hub.freebsd.org (Postfix) with ESMTP id 78AF337B41B for ; Sat, 27 Apr 2002 21:49:00 -0700 (PDT) Received: from gateway.posi.net ([12.236.90.177]) by rwcrmhc51.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020428044900.BDQW8969.rwcrmhc51.attbi.com@gateway.posi.net>; Sun, 28 Apr 2002 04:49:00 +0000 Received: from localhost (kbyanc@localhost) by gateway.posi.net (8.11.6/8.11.6) with ESMTP id g3S4mwg04391; Sat, 27 Apr 2002 21:48:59 -0700 (PDT) (envelope-from kbyanc@posi.net) X-Authentication-Warning: gateway.posi.net: kbyanc owned process doing -bs Date: Sat, 27 Apr 2002 21:48:58 -0700 (PDT) From: Kelly Yancey To: Garance A Drosihn Cc: Alfred Perlstein , Subject: Re: Thinking about more work on 'patch' In-Reply-To: <20020428035129.GS1530@elvis.mu.org> Message-ID: <20020427214516.A4372-100000@gateway.posi.net> MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-arch@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG On Sat, 27 Apr 2002, Alfred Perlstein wrote: > * Garance A Drosihn [020427 19:30] wrote: > > > > Once done, we could then toss both of the other two versions > > into the attic. Is this worth doing? > > I think it's a worthwhile task, the more truly free code in > the base, the better off we are. Thanks for taking the time > to look into this and offering to do it, it would really be > a nice thing to see done. > > -Alfred > "Me too". If you follow through with this, could you please close PR 19642 then. It is a set of patches I did quite some time ago to merge changes to the BSD-licensed patch that OpenBSD had made. I'm sure the patches are quite bit-rotten by now and I've been meaning to go back and look at it again. But obviously, if you import the OpenBSD patch outright then the whole matter is moot. Good luck, Kelly kbyanc@{posi.net,FreeBSD.org} To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-arch" in the body of the message