filepro menus and Ctrl-S - maybe Anzio setting?

[Bruce Easton]

On 12/9/10 11:42 PM, Bruce Easton wrote:
> On 12/9/10 9:16 PM, Kenneth Brody wrote:
>> On 12/9/2010 8:11 PM, Bruce Easton wrote:
>>> I wanted to see this first-hand, so I loaded demo of latest Anzio
>>> Lite onto
>>> this vista partition, accepting, I think all the defaults, and saying
>>> yes to
>>> older SCO mode question.  Very easy install.  And filepro's dpromenu
>>> came
>>> up in color beautifully.   Found one of the 19-option menus that had
>>> been adjusted to less than 19 lines and put it back to 19 lines.
>>>
>>> Sure enough, works OK from prompt or from option G on dpromenu,
>>> but from a calling menu - as George said, 'LOCK' appears at lower
>>> right and you have to key Alt-U to be able to navigate/select anything.
>>>
>>> (fp 5.0.14 by the way)
>>>
>>> Then things got really interesting.  I took a look around and found that
>>> some of the filepro executables (including dmakemenu, runmenu) did
>>> not get the SUID bit set correctly from the setperms prog.  So I
>> Well, runmenu isn't supposed to have the setuid bit on.
> I'll check the system that I referenced, but even with it on, it doesn't
> pose a problem on that system on which we've exercised menus for quite
> some time.
-----
Yes - I see on several other systems that runmenu doesn't have setuid 
bit set.  And after running setperms, it was not set.
-----
>>> referenced another Linux box, did an "ls -l|grep rws" standing in fp and
>>> lib to help refresh my memory and proceeded to fix these perms.
>>> Well that did not help.
>> [...]
>>> Then I looked at the perms on the problem menu file itself. It was 777.
>>> I thought that it didn't need and probably should have that - it was
>>> already owned by filepro, so I changed it to 600.  Boom.  It no
>>> longer had a problem!  So for kicks, I changed the perms on the
>>> newly ported menu to 777 and walla - Anzio started turning the lock
>>> on on that menu.  (And by the way - this all as far as I can tell
>>> happens
>>> on menus with 19 items, but i'm suspicious that maybe this is the only
>>> obvious side-effect and that these ctrl chars in all menus are not
>> Which makes even less sense than before.  The only difference that
>> permissions on menu files will make to runmenu is whether or not it
>> can be read.  There should be absolutely no difference to runmenu
>> between the 644 that it should be and the 777 you changed it to.
> I would think so too.  But that one permissions change would cause the
> Anzio Lite to turn on or off the lock as soon as the menu was presented
> (depending on whether the permissions was 600 or 777 - I will try this
> test again with 644 vs. 777).
-----
Again, after setperms was run, the menus got 644 and their scripts 755.  
And this did eliminate Anzio turning on lock on the problem menu.  I did 
test afterward (to see if other permission changes by setperms might 
eliminate the problem even if one menu is set wrong), but a setting of 
700, 755, 744, or 777 permissions for that file - that change alone 
(setting to one of those permission settings I just mentioned) would 
cause Anzio Lite to turn on lock once that menu had loaded.   I've not 
used Anzio much so I've never seen this with a menu before.  I've ssh'd 
to other systems from putty and mac term and come across menu systems 
where people just went wild and set everything in the menu dir to 777 
and I never saw that lockup.    So obviously it is very important to get 
the permissions right in the menu dir.
-----

>>> being treated properly - I mean we know these files are all supposed
>>> to have one of those chars at the top right?)
>> What do you mean "one of those chars"?  The top-right of the screen
>> will be the "menu version" string that you set in dmakemenu.  The
>> value stored in the first byte of the menu file is never shown by
>> filePro.
> sorry..  the control character or first byte of menu file as you say.  I
> understand that it is not supposed to show. And I have not seen it show
> anywhere.  What I am wondering is if something is mis-interpreting that
> initial byte - that starts the file (^S for 19 option file), then what's
> to say it's not also mis-interpreting a ^A that starts the file for a
> one-option menu.  I'm just wondering if the ^S is the only one that is
> causing a perceivable effect and that the problem is not really just
> limited in this case to menus with 19 items.
>> [...]
>>> I also re-saved the problem menu once it had 'correct' perms, but
>>> it did not change its size which is still different than the other
>>> one that looks and behaves the same way under the same
>>> circumstances, but has a different size.
>> What sizes are you seeing for menus?  They should all be 4719.
>>
> I think those did show at that file size, but I'll reconnect from the
> other partition and check it again.
----
They are 4719.
----
>> [...]
>>> Anyway, that's what I tried - maybe this will ring a bell with
>>> someone.  So, as it stands, if the perms of menu files (not the
>>> scripts) are 600, then they are OK.
>> No, they're not.  They should be 644, or else only root and filePro
>> can use them.  (Unless, that is, you set the setuid bit in runmenu,
>> which is also wrong.)
> Who would need to use a menu besides filepro?  I'll run setperms and if
> messes up, I'll try to get them to 644 and the scripts to 755.
>> Run setperms.
> Well I think that's what left things in a strange state to start with.
> I've had trouble with setperms before.  It certainly didn't do the 4755
> for SUID on anything under fp.  But I can easily get that fixed if it
> messes it up.
-----
After running setperms, the menus were 644 (and 755 for scripts).   None 
of the programs in fp or fp/lib got the suid bit, so I guess this is 
normal for an fp install on Linux.  I was able to add a new file, 
screen, add data and view the data via clerk after running setperms and 
without any suid bits set.

The only problem that remained was when canceling out of defining a menu 
script, it would show very briefly at the bottom of the screen 
**segmentation violation** (very briefly, but I could make out that 
phrase), and then blow out to dpromenu.  I tried this on some other 
Linux boxes and it did it there as well, so I guess this is nothing 
new.  And as Brian mentioned about this behavior, is doesn't seem to do 
any harm along the way; saving does stay in the menu as he said.
-----
Bruce

Bruce Easton
STN, Inc.