From owner-freebsd-hackers Thu Nov 13 14:34:42 1997 Return-Path: Received: (from root@localhost) by hub.freebsd.org (8.8.7/8.8.7) id OAA28035 for hackers-outgoing; Thu, 13 Nov 1997 14:34:42 -0800 (PST) (envelope-from owner-freebsd-hackers) Received: from alpo.whistle.com (alpo.whistle.com [207.76.204.38]) by hub.freebsd.org (8.8.7/8.8.7) with ESMTP id OAA28029 for ; Thu, 13 Nov 1997 14:34:37 -0800 (PST) (envelope-from julian@whistle.com) Received: (from daemon@localhost) by alpo.whistle.com (8.8.5/8.8.5) id OAA20848; Thu, 13 Nov 1997 14:22:03 -0800 (PST) Received: from UNKNOWN(), claiming to be "current1.whistle.com" via SMTP by alpo.whistle.com, id smtpd020843; Thu Nov 13 14:21:55 1997 Message-ID: <346B7D0F.446B9B3D@whistle.com> Date: Thu, 13 Nov 1997 14:19:59 -0800 From: Julian Elischer Organization: Whistle Communications X-Mailer: Mozilla 3.0Gold (X11; I; FreeBSD 2.2-CURRENT i386) MIME-Version: 1.0 To: sos@FreeBSD.dk CC: hackers@FreeBSD.ORG Subject: Re: SUID-Directories patch References: <199711132135.WAA00279@sos.freebsd.dk> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Sender: owner-freebsd-hackers@FreeBSD.ORG X-Loop: FreeBSD.org Precedence: bulk S?ren Schmidt wrote: > > In reply to Julian Elischer who wrote: > > I'd like to move this to 2.2.x > > > > It is all hidden behind #ifdef SUIDDIR > > so I can guarantee that it won't BREAK anything. > > > > I really need it in 2.2 rather than 3.0 so I'd like to merge it in from > > -current later thes afternoon if I don't hear any objections. > > Objection. If you need this for Whistle, you should keep it in your > own tree, its does NOT belong in the generic FreeBSD tree. > I asked if people thought it would be useful.. I got 20 replies saying that YES it would be useful, so I've added it to -current. It's #ifdef'ed out as it is. You need to specifically compile it in to make use of it. Most people I know who are running company file servers for this sort of thing are running 2.2.x rather than 3.0, so making it only available in 3.0 doesn't help them. We are running it here on 2.2 on N machines (where N is a large number) so the 2.2 patches are much more tested than the 3.0 version. I have a 2.2 set of patches that are tested and known to work sitting in my freebsd CVS-d tree waiting for the words "cvs commit" but I haven't said them. but as I said. they are bracketted in #ifdef SUIDDIR #endif so without the change there are 0 bytes of binary change in the kernel. The risk is minimal. When we started the -stable/-current split, the requirement for adding code to -stabe branches was: 1/ "Not breaking any existing features/interfaces" [this is a NEW feature] 2/ "Must be tested" [how many 0s do I need to put on the number of machines running this before it's 'tested'?] If it's not in 2.2 it can't be tested in 2.2,and We've tested it as much as we can in our application it's time for wider distribution.. what I'm asking is: "Can I check in some code that is presently #ifdef'd out" is this such a risk? the request to do this came from the Samba developers as a way to make things work the way that PC usesrs expect. We did so for them because their product is integral to ours. I don't know if they will be getting the same changes into Linux but it wouldn't surprise me.