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 PROTECT
Robert,
the problem wan't with access(2) but with preceding setresuid(2)
calls. There was a false widening conversion taking place in
linux_uid16.c.
Various setXXid() calls allow the caller to set several ids at once,
or leave them unchanged by specifying the magic parameter -1.
Unfortunately u
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 with
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 NAM
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
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.
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 c