bugGforth - Bugs: bug #26261, Seeing assembly code on Mac OS X...

 
 

bug #26261: Seeing assembly code on Mac OS X robs me of my identity

Submitted by:  John T. Wodder II <minimiscience>
Submitted on:  Tue 21 Apr 2009 01:49:28 AM UTC  
 
Category: NoneSeverity: 3 - Normal
Item Group: NoneStatus: Fixed
Privacy: PublicAssigned to: Bernd Paysan <paysan>
Open/Closed: Open

Add a New Comment (Rich MarkupRich Markup):
   

You are not logged in

Please log in, so followups can be emailed to you.

 

Fri 02 Apr 2010 07:31:52 PM UTC, comment #4:

The last round of updates on Mac OS X seem to fix this problem - while I could reproduce it before, it's now gone. This was a genuine Mac OS X bug, and should now be fixed.

Bernd Paysan <paysan>
Project AdministratorIn charge of this item.
Wed 22 Apr 2009 07:52:24 AM UTC, comment #3:

Thanks for the feedback. Your pointer to launchd may help Bernd to
reproduce the problem.

It's not surprising that you don't see this with the 32-bit version
because by default it does not use DISASM-GDB. My guess is that you
will see the same effect if you do:

' disasm-gdb is discode
see +

Anton Ertl <anton>
Project Administrator
Wed 22 Apr 2009 01:49:59 AM UTC, comment #2:

Looking into this more, I've found that using SEE on built-in commands somehow causes the "launchd" program to exit due to a segmentation fault, with this near the top of the crash report:

This explains the inability to open applications. Unfortunately, I still have no idea exactly why this is happening. I have found that this problem only occurs when Gforth is configured to be 64-bit; invoking "configure" with no options leads to the creation of an executable without this problem, albeit slightly slower and with smaller numbers. The only possible cause that I can definitively rule out is Leopard's quarantining of downloaded files; when I realized that the source & executable were quarantined, I removed the extended attributes, only for the problem to persist.

I have no idea what differences could cause the problem to not occur for you, though if you ask for any specific hardware or software details of my computer, I can most likely give them to you.

John T. Wodder II <minimiscience>
Tue 21 Apr 2009 05:07:17 PM UTC, comment #1:

Bernd Paysan has tried this on MacOS X 10.5.6, and could not reproduce
the problem. Maybe you can follow the suggestions I made in my mail,
and find out more information about the issue, which we can then use
somewhere in the installation.

To have this stuff in the bug tracker and in case my mail has not
reached you, here I reproduce my text:

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 Ertl <anton>
Project Administrator
Tue 21 Apr 2009 01:49:28 AM UTC, original submission:

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:
and "whoami" displays my username. After using "see", even in a separate Terminal window, the output from "id" changes to:
(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:
I'm quite sure that my computer qualifies for the performance boost this configuration gives; for comparison, the output from "uname -a" is:
My only other deviation from the basic installation instructions was to use "sudo make install" instead of "make install" for permissions reasons.

John T. Wodder II <minimiscience>

 

(Note: upload size limit is set to 16384 kB, after insertion of the required escape characters.)

Attach File(s):
   
   
Comment:
   

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -unavailable- added by paysan (Posted a comment)
  • -unavailable- added by anton (Posted a comment)
  • -unavailable- added by minimiscience (Submitted the item)
  •  

    Do you think this task is very important?
    If so, you can click here to add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.

     

    Please enter the title of George Orwell's famous dystopian book (it's a date):

     

     

    Follow 3 latest changes.

    Date Changed By Updated Field Previous Value => Replaced By
    Fri 02 Apr 2010 07:31:52 PM UTCpaysanStatusWorks For Me=>Fixed
    Tue 21 Apr 2009 05:07:17 PM UTCantonStatusNone=>Works For Me
      Assigned toNone=>paysan

    Back to the top


    Powered by Savane 3.1-cleanup