Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 12 Mar 2002 21:33:32 -0800 (PST)
From:      Julian Elischer <julian@elischer.org>
To:        Maxim Konovalov <maxim@macomnet.ru>
Cc:        Kris Kennaway <kris@obsecurity.org>, Robert Watson <rwatson@FreeBSD.ORG>, current@FreeBSD.ORG
Subject:   Re: eaccess(2) breaks execution of 4.x binaries on 5.x
Message-ID:  <Pine.BSF.4.21.0203122131420.72756-100000@InterJet.elischer.org>
In-Reply-To: <20020313081047.R16064-100000@news1.macomnet.ru>

next in thread | previous in thread | raw e-mail | index | archive | help
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




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.4.21.0203122131420.72756-100000>