On Sun, 7 Oct 2001, Georg-W. Koltermann wrote:
> Hi Robert, > > it doesn't seem to be securelevel-related. sysctl(8) says: > > hunter[5]$ sysctl kern.securelevel > kern.securelevel: -1 > > I also hacked the securelevel_g[et] routines to immediately return 0 > as you suggested, and it doesn't make a difference. > > Besides, securelevel_g[et] doesn't seem to be used much. I think I > found only one reference when doing a find/grep in /usr/src/sys. And > there are just a few hard-coded tests of securelevel > 0 as well. Then you must be running a souce tree from before the commits that I was worried about--in my -CURRENT tree, I see about 22 references to securelevel_gt(), and 7 to securelevel_ge() (including prototype and implementation). On September 26, I committed a fairly sweeping set of changes to replace direct securelevel checks with calls to securelevel_g[et]() so as to support per-jail securelevels, and these commits were the ones I was concerned might be causing the problems you're experiencing. > I ran the vmware command through ktrace(1) (had to do that as root since > it won't trace a SUID program for a normal user), and it does get an > error return from an access(2) on .Xauthority: > > 1207 vmware CALL access(0xbfbff759,0x4) > 1207 vmware NAMI "/compat/linux/home/hunter/gwk/.Xauthority" > 1207 vmware NAMI "/home/hunter/gwk/.Xauthority" > 1207 vmware RET access -1 errno -13 Unknown error: -13 > > It seems I am going to debug the access() call next. I'm a little surprised that they're calling access(). Are you using the linux_kdump from the ports collection, btw? Otherwise the system calls aren't listed right, due to differences in system call number. 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
