From owner-freebsd-current Tue Mar 12 21:40:13 2002 Delivered-To: freebsd-current@freebsd.org Received: from rwcrmhc51.attbi.com (rwcrmhc51.attbi.com [204.127.198.38]) by hub.freebsd.org (Postfix) with ESMTP id 4F1FA37B405; Tue, 12 Mar 2002 21:40:09 -0800 (PST) Received: from InterJet.elischer.org ([12.232.206.8]) by rwcrmhc51.attbi.com (InterMail vM.4.01.03.27 201-229-121-127-20010626) with ESMTP id <20020313054008.XQCC2626.rwcrmhc51.attbi.com@InterJet.elischer.org>; Wed, 13 Mar 2002 05:40:08 +0000 Received: from localhost (localhost.elischer.org [127.0.0.1]) by InterJet.elischer.org (8.9.1a/8.9.1) with ESMTP id VAA72774; Tue, 12 Mar 2002 21:33:35 -0800 (PST) Date: Tue, 12 Mar 2002 21:33:32 -0800 (PST) From: Julian Elischer To: Maxim Konovalov Cc: Kris Kennaway , Robert Watson , current@FreeBSD.ORG Subject: Re: eaccess(2) breaks execution of 4.x binaries on 5.x In-Reply-To: <20020313081047.R16064-100000@news1.macomnet.ru> Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG any change that has to be added to 4.x tomake it run on 5.x is the wrong answer. 4.x binaries should all run on 5.x (unless something was accidentally committed to 4.x that should be backed out.) any change for allowing 4.x binaries to run on 5.x should be done on the 5.x side of things, (unless I've misunderstood the problem here) regards, Julian On Wed, 13 Mar 2002, Maxim Konovalov wrote: > > Kris, Robert, > > On 20:11-0800, Mar 12, 2002, Kris Kennaway wrote: > > > On Tue, Mar 12, 2002 at 10:59:07PM -0500, Robert Watson wrote: > > > > > > On Tue, 12 Mar 2002, Kris Kennaway wrote: > > > > > > > Subject says it all, really; this is the cause of part of my problems in > > > > getting 5.x packages built on the bento cluster, because it seems that > > > > /bin/sh has come to depend on this syscall. Executing a 5.x /bin/sh on > > > > a 4.x system causes a SIGSYS if it hits this code (e.g. test -x > > > > /some/binary) > > > > > > > > Can this syscall be MFCed soon? > > > > > > Today it's eaccess(), tomorrow it's KSE system calls, ACL system calls, > > > MAC system calls, 64-bit stat and ino_t, dev_t, devfs, ... > > > > > > Certainly we can MFC eaccess(), but that's not going to make the problem > > > go away. Fundamentally our model is backward compatibility, not forward > > > compatibility. We need to build 5.0 packages on 5.0. > > > > Well, I've backed out the eaccess() use in /bin/test for now. I agree > > with you that ultimately this model will fail, but the longer we can > > delay it the easier my life will be trying to manage the cluster and > > get packages built. > > I can replace my eaccess(2) patch for test(1) by a workaround I am > planning to commit to -stable. Is it desirable solution? > > Index: test.c > =================================================================== > RCS file: /home/ncvs/src/bin/test/test.c,v > retrieving revision 1.29.2.4 > diff -u -r1.29.2.4 test.c > --- test.c 6 Feb 2002 17:37:13 -0000 1.29.2.4 > +++ test.c 24 Feb 2002 21:26:38 -0000 > @@ -195,6 +195,8 @@ > int argc; > char **argv; > { > + gid_t gid, egid; > + uid_t uid, euid; > int i, res; > char *p; > char **nargv; > @@ -224,14 +226,20 @@ > } > > /* XXX work around the absence of an eaccess(2) syscall */ > - (void)setgid(getegid()); > - (void)setuid(geteuid()); > + gid = getgid(); > + egid = getegid(); > + uid = getuid(); > + euid = geteuid(); > + (void)setregid(egid, gid); > + (void)setreuid(euid, uid); > > t_wp = &argv[1]; > res = !oexpr(t_lex(*t_wp)); > > if (*t_wp != NULL && *++t_wp != NULL) > syntax(*t_wp, "unexpected operator"); > + (void)setregid(gid, egid); > + (void)setreuid(uid, euid); > > return res; > } > > -- > Maxim Konovalov, MAcomnet, Internet-Intranet Dept., system engineer > phone: +7 (095) 796-9079, mailto:maxim@macomnet.ru > > > To Unsubscribe: send mail to majordomo@FreeBSD.org > with "unsubscribe freebsd-current" in the body of the message > To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message