Date: Tue, 12 Mar 2002 20:11:08 -0800 From: Kris Kennaway <kris@obsecurity.org> To: Robert Watson <rwatson@FreeBSD.org> Cc: Kris Kennaway <kris@obsecurity.org>, current@FreeBSD.org Subject: Re: eaccess(2) breaks execution of 4.x binaries on 5.x Message-ID: <20020312201108.A80263@xor.obsecurity.org> In-Reply-To: <Pine.NEB.3.96L.1020312225739.36618F-100000@fledge.watson.org>; from rwatson@FreeBSD.org on Tue, Mar 12, 2002 at 10:59:07PM -0500 References: <20020312191211.A78611@xor.obsecurity.org> <Pine.NEB.3.96L.1020312225739.36618F-100000@fledge.watson.org>
next in thread | previous in thread | raw e-mail | index | archive | help
--AhhlLboLdkugWU4S Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Mar 12, 2002 at 10:59:07PM -0500, Robert Watson wrote: >=20 > On Tue, 12 Mar 2002, Kris Kennaway wrote: >=20 > > 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)=20 > >=20 > > Can this syscall be MFCed soon?=20 >=20 > 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, ...=20 >=20 > 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.=20 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 haven't yet tested the stability of 5.0 clients in the bento cluster; hopefully it won't be too bad, but any stability problems cause interruptions and increased work for me. For example, for some reason the gohan machines won't reboot on their own in response to a reboot command, and have to be power cycled (they mostly come back up okay if they panic, but sometimes they get stuck and need power cycling still). This means I can't currently automate booting them into a 5.0 nfs snapshot when I want to build 5.0 packages. Kris --AhhlLboLdkugWU4S 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 iD8DBQE8jtFcWry0BWjoQKURAh3gAJ0d8cFxrFLeHbBnzmhTXtfoWrQcRACgv3g6 /XMRuqJQ1dQ0Lj8CVD+WeHo= =cEQB -----END PGP SIGNATURE----- --AhhlLboLdkugWU4S-- To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20020312201108.A80263>