filepro menus and Ctrl-S - maybe Anzio setting?

[Bruce Easton]

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.
>
>> 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).
>
>> 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.
> [...]
>> 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.
>
> [...]
>