Re: [Bug-gforth] [bug #26261] Seeing assembly code on Mac OS X robs me

[Anton Ertl]

John T. Wodder II wrote:
> 
> 
> URL:
>   <http://savannah.gnu.org/bugs/?26261>
> 
>                  Summary: Seeing assembly code on Mac OS X robs me of my
> identity
>                  Project: Gforth
>             Submitted by: minimiscience
>             Submitted on: Tue 21 Apr 2009 01:49:28 AM GMT
>                 Category: None
>                 Severity: 3 - Normal
>               Item Group: None
>                   Status: None
>                  Privacy: Public
>              Assigned to: None
>              Open/Closed: Open
>          Discussion Lock: Any
> 
>     _______________________________________________________
> 
> Details:
> 
> I just compiled & installed Gforth 0.7.0 on Mac OS X 10.5.6 (Intel MacBook),
> and I've encountered a strange problem: whenever I use "see" to print out a
> built-in command (i.e., one defined in assembly/machine code rather than as a
> composite of simpler Forth commands), I afterwards seem to somehow lose my
> username and some basic permissions.  Everything else with Gforth seems to be
> fine; as far as I can tell, this only happens when "see"ing built-in
> commands.
> 
> I've tried this at least three times, and the behavior is always the same. 
> Prior to using "see" in this way, the output from "id" is:
> 
> uid=501(jwodder) gid=20(staff)
> groups=20(staff),101(com.apple.sharepoint.group.1),98(_lpadmin),81(_appserveradm),79(_appserverusr),80(admin)
> 
> and "whoami" displays my username.  After using "see", even in a separate
> Terminal window, the output from "id" changes to:
> 
> uid=501 gid=20(staff)
> groups=20(staff),101(com.apple.sharepoint.group.1),98(_lpadmin),81(_appserveradm),79(_appserverusr),80(admin)
> 
> (note the lack of my username), and "whoami" just prints out "501".  In
> addition, I am no longer able to empty the Trash (as I apparently lack
> permissions that I should have), and attempting to open any new applications
> results in an error.  There may be more side-effects, but I have no desire to
> seek them out.  This username-less state can be easily resolved by logging out
> & then logging back in again, but it's still quite inconvenient and a bit
> disturbing.
> 
> For reference, I invoked "configure" with:
> 
> ./configure CC='gcc -arch x86_64' --build=x86_64-apple-darwin9.6.0

That means you are using DISASM-GDB for SEEing primitives.  This word
invokes a number of shell commands (in particular: type mktemp echo
gdb rm); my guess is that one of these commands (at least as invoked
by Gforth) has the side effect you observe.

Since you still have the same uid (and are in the same groups), you
should still have the same permissions, and tools should be able to
look up your user name in /etc/passwd (if they look there) in the
traditional Unix security model.  I guess what you are seeing is an
effect of some additional security framework, but I am not familiar
with that (whatever it is), so I cannot really help you there.

The following are just educated guesses: I have read about SELinux
that someone needs to finetune the policies for the various
applications. By default they are restrictive, and if you notice that
it is forbidding something that's ok, you should allow that.  My guess
is that gdb's use of ptrace() to attach to the gforth process looks
suspicious to your security framework and it then disallows some
things.  Maybe you find something about this in the logs of your
security framework.

- anton