Hi, all,
Due to mail trouble, I couldn't join this thread, but I submitted PR
via web on this problem fix (kern/31122). Your patch seems better
than what I attached to the PR (I didn't care about gid's in my patch).
My PR should be closed when the patch is commited.
In article [EMAIL
No, I wan't using linux_kdump, thanks for the education.
Today I've installed linux_kdump from the package on
jp.current.freebsd.org, and now I get
1207 vmware CALL linux_access(0xbfbff759,0x4)
1207 vmware NAMI /compat/linux/home/hunter/gwk/.Xauthority
1207 vmware NAMI
So normally vmware runs setuid root, which means that the 'real' uid and
gid will be the normal user, as opposed to the root user. '0x4' on
FreeBSD would constitute R_OK -- a quick glance at my local Linux box
demonstrates that it has the same meaning there. If you run the 'access'
command
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
Hi,
I have applied the KSE patches to vmware2 that were posted on
http://www.ripe.net/home/mark/files/vmware2_kse.patch.tgz. I can now
build vmware2, but run into a number of permission problems running
it:
1. Xlib: connection to :0.0 refused by server
Xlib: Client is not authorized to
There have been a number of permission-related changes in the tree of
late, in particular relating to securelevel support. I haven't
experienced any local problems running the new code, but there is always
the potential for such a problem, especially in areas of the code I'm not
actively using.
