Re: eaccess(2) breaks execution of 4.x binaries on 5.x
On Tue, Mar 12, 2002 at 09:33:32PM -0800, Julian Elischer wrote: 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) Yes: see my followup. Kris msg36020/pgp0.pgp Description: PGP signature
Re: eaccess(2) breaks execution of 4.x binaries on 5.x
On Wed, Mar 13, 2002 at 08:15:30AM +0300, Maxim Konovalov wrote: I can replace my eaccess(2) patch for test(1) by a workaround I am planning to commit to -stable. Is it desirable solution? Well, this won't solve my problem since I'm trying to run the 5.x binary. I'm not immediately familiar with the issues surrounding eaccess(). Kris msg36021/pgp0.pgp Description: PGP signature
Re: eaccess(2) breaks execution of 4.x binaries on 5.x
On 02:00-0800, Mar 13, 2002, Kris Kennaway wrote: On Wed, Mar 13, 2002 at 08:15:30AM +0300, Maxim Konovalov wrote: I can replace my eaccess(2) patch for test(1) by a workaround I am planning to commit to -stable. Is it desirable solution? Well, this won't solve my problem since I'm trying to run the 5.x Maybe I was unclear but it will solve your problem. My proposal is: - back test/test.c rev. 1.43 out, - commit a workaround I sent in previous latter to -current. binary. I'm not immediately familiar with the issues surrounding eaccess(). Kris -- Maxim Konovalov, MAcomnet, Internet-Intranet Dept., system engineer phone: +7 (095) 796-9079, mailto:[EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: eaccess(2) breaks execution of 4.x binaries on 5.x
On Wed, Mar 13, 2002 at 01:24:36PM +0300, Maxim Konovalov wrote: On 02:00-0800, Mar 13, 2002, Kris Kennaway wrote: On Wed, Mar 13, 2002 at 08:15:30AM +0300, Maxim Konovalov wrote: I can replace my eaccess(2) patch for test(1) by a workaround I am planning to commit to -stable. Is it desirable solution? Well, this won't solve my problem since I'm trying to run the 5.x Maybe I was unclear but it will solve your problem. My proposal is: - back test/test.c rev. 1.43 out, - commit a workaround I sent in previous latter to -current. Well, eaccess(2) is presumably a good idea, so it would be better to just MFC it :) Kris msg36025/pgp0.pgp Description: PGP signature
Re: eaccess(2) breaks execution of 4.x binaries on 5.x
On 03:38-0800, Mar 13, 2002, Kris Kennaway wrote: On Wed, Mar 13, 2002 at 01:24:36PM +0300, Maxim Konovalov wrote: On 02:00-0800, Mar 13, 2002, Kris Kennaway wrote: On Wed, Mar 13, 2002 at 08:15:30AM +0300, Maxim Konovalov wrote: I can replace my eaccess(2) patch for test(1) by a workaround I am planning to commit to -stable. Is it desirable solution? Well, this won't solve my problem since I'm trying to run the 5.x Maybe I was unclear but it will solve your problem. My proposal is: - back test/test.c rev. 1.43 out, - commit a workaround I sent in previous latter to -current. Well, eaccess(2) is presumably a good idea, so it would be better to just MFC it :) Agree. Kris -- Maxim Konovalov, MAcomnet, Internet-Intranet Dept., system engineer phone: +7 (095) 796-9079, mailto:[EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: eaccess(2) breaks execution of 4.x binaries on 5.x
On Tue, 12 Mar 2002, Julian Elischer wrote: 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) Yes, the problem here is that Kris is building and running a 5.x world on a 4.x kernel in a chroot to support the build cluster. Common binaries such as sh are just now beginning to rely on the new kernel functionality (a trend that will continue, as I pointed out), and my belief is the model being used is flawed as anything other than a short term thing. On the other hand, there's no harm in MFC'ing eaccess(), since it's a generally useful thing. However, as soon as the 64-bit UFS2 work starts coming in, and the new system calls are brought in to support that, even basic applications such as 'sh' are going to stop working again, due to stat(). But my feeling is that's actually OK given the direction: 4.x kernel 5.x kernel 4.x binariesREQUIREDREQUIRED 5.x binariesDEGRADING REQUIRED This case falls squarely into the 'DEGRADING' category, given the approach of new functionality. For example, ls will shortly learn about ACL system calls, which while present in the -STABLE aren't implemented. Likewise, configure scripts that test the behavior of system calls will also start failing in appropriately. To get us 5.0-DP1 packages, sure, MFC eaccess(). We'll just need to make sure that over the next month or two, -CURRENT is in a position where it can run safely on the package cluster to support 5.0 package builds. I can MFC eaccess() later today, assuming there are no objections. I've been meaning to for a while, so that I can merge it into Darwin. Robert N M Watson FreeBSD Core Team, TrustedBSD Project [EMAIL PROTECTED] NAI Labs, Safeport Network Services To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: eaccess(2) breaks execution of 4.x binaries on 5.x
On Wed, 13 Mar 2002, Maxim Konovalov wrote: I believe you have :-) ummm but we =have never guaranteed that N+1 binaries will run on N systems. To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
eaccess(2) breaks execution of 4.x binaries on 5.x
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? Kris msg35996/pgp0.pgp Description: PGP signature
Re: eaccess(2) breaks execution of 4.x binaries on 5.x
On Tue, Mar 12, 2002 at 07:12:11PM -0800, Kris Kennaway wrote: Subject says it all, really Herf. Subject is the wrong way around; this breaks execution of 5.x binaries under 4.x, not the other way around. ; 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. Actually it's /bin/test. Kris msg35998/pgp0.pgp Description: PGP signature
Re: eaccess(2) breaks execution of 4.x binaries on 5.x
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. Robert N M Watson FreeBSD Core Team, TrustedBSD Project [EMAIL PROTECTED] NAI Labs, Safeport Network Services To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: eaccess(2) breaks execution of 4.x binaries on 5.x
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 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 msg36001/pgp0.pgp Description: PGP signature
Re: eaccess(2) breaks execution of 4.x binaries on 5.x
rwatson Certainly we can MFC eaccess(), but that's not going to make rwatson the problem go away. Fundamentally our model is backward rwatson compatibility, not forward compatibility. We need to build rwatson 5.0 packages on 5.0. That's why I build FreeBSD 5-current snapshots on a 5-current box. Note that we have already experienced such a situation before (at least in September 1999, sigset_t change). -- - Makoto `MAR' Matsushita To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
Re: eaccess(2) breaks execution of 4.x binaries on 5.x
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 - 1.29.2.4
+++ test.c 24 Feb 2002 21:26:38 -
@@ -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:[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: eaccess(2) breaks execution of 4.x binaries on 5.x
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.c6 Feb 2002 17:37:13 - 1.29.2.4
+++ test.c24 Feb 2002 21:26:38 -
@@ -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:[EMAIL PROTECTED]
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
To Unsubscribe: send mail to [EMAIL PROTECTED]
with unsubscribe freebsd-current in the body of the message
Re: eaccess(2) breaks execution of 4.x binaries on 5.x
On 21:33-0800, Mar 12, 2002, Julian Elischer wrote: 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) I believe you have :-) Kris cannot run /bin/sh from 5.x on 4.x because of absence eaccess(2) in 4.x. 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 [...] -- Maxim Konovalov, MAcomnet, Internet-Intranet Dept., system engineer phone: +7 (095) 796-9079, mailto:[EMAIL PROTECTED] To Unsubscribe: send mail to [EMAIL PROTECTED] with unsubscribe freebsd-current in the body of the message
