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

> 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

Reply via email to