Re: Blacklisted Shell Script? --- not quite SOLVED ---

Brad, many, many thanks for your patience and persistence. It's been a 
real eye-opener - even if I don't understand some of what I'm looking at !

First of all, you were so right - Fire-secs _does_ get updated. That got 
my attention. Time for a sprinkle of "echoes" to see where things go off 
the rails.

Although I ran the script on another box (the host for where I'm typing 
this), too many links to mend etc, so I'll resume efforts on the server 
box tomorrow.

Best wishes;
Dave

Brad Barnett wrote:
> One last thing.
>
> Certain rootkits can overwrite /bin/bash with security impaired versions
> of the same.  Some of these versions of bash can be very old, static
> compiled binaries....
>
> It wouldn't hurt to run a few checks, to validate the legitimacy of your
> bash executable.  
>
> On Fri, 3 Jul 2009 18:04:30 -0400
> Brad Barnett <[email protected]> wrote:
>
>   
>> I really doubt it is the size.  I've seen shell scripts much larger than
>> 10k...
>>
>> You mention that it is as if you haven't run the script at all.
>> However, unless you have output from that script, successfully running
>> it will produce no output!  Keep that thought while reading below ..
>>
>> My comments with the 'echo' statements, were to see if the script was
>> executing at all.  There could be a yet unknown bug with your current
>> version of bash (most sh binaries are just links to bash).
>>
>> By placing echo statements at the top of your script, you'll know for
>> sure -- does the script run or not?  You are assuming the script is
>> not running, and you *must* verify that first, by some means you can
>> easily identify.  A simple echo meets that.  
>>
>> I see the the first line executing in your original script is this:
>>
>> date +%s > /home/whacker/IP-Update/Unix-seconds/Fire-secs
>>
>> Have you checked to see if Fire-secs is updated successfully?  That's as
>> good of a check as slapping some echo statements in there.  Run the
>> script twice... does the value in Fire-secs change each time?
>>
>> Alternative to a 'bug', could be an update (bug fix) to bash that fixed
>> a certain looseness to how bash interprets an if statement or the like.
>> That could have the effect of inverting a match in an if or while
>> statement, as well.  How much logic in your script would be shut down,
>> if certain if statements stopped working?
>>
>> Verify that script works, don't assume.  Use an echo or some other means
>> at the very top, outside of all logic loops...
>>
>> One last thing.  Do you have another box?  Do you have vmware or some
>> emulator around?  Try running this same script on that other box... and
>> of course make sure it is not with the same versions of software..
>>
>> On Fri, 03 Jul 2009 15:18:06 -0400
>> Dave <[email protected]> wrote:
>>
>>     
>>> Mike, and Brad, I am proceeding on the assumption that  somehow, the 
>>> end-of-rope limit on my system for bash script size changed recently.
>>> My previous bash script (with comments and other crud) was 10.2KB, and
>>> a primitive barebones collection of essentials (lines cannibalized
>>> from the original) is so far 1.6KB, and it runs. I'll creep upwards
>>> from there, but hints on a more "scientific" method of how to
>>> determine the size limit would be welcomed.
>>>
>>> What am I up to? http://web.ncf.ca/carpe.machinam/NCF/Static.html
>>> and http://web.ncf.ca/carpe.machinam/NCF/sanitized-ST-585-restore.sh
>>> tell the story. A big concern is testing for the case where the NCF
>>> ftp service fails silently, and without testing for this situation 
>>> periodically, I'll be unaware what my home IP address is.
>>>
>>> Changes to this system? Yes, Fedora 10 is frequently pushing patches
>>> and fixes (including offers to head to Fedora 11), and recently I
>>> flirted with replacing the onboard video with a PCI Nvidia GeForce
>>> 8400GS. The new video card was a treat to the eyes, between frequent
>>> system lock-ups.
>>>
>>> These lock-ups required hard-reset, and then wait for the software 
>>> RAID-1 to repair itself. After much consternation, I am back to the 
>>> onboard intel video.
>>>
>>> Again, the most logical explanation I can think of for size making a 
>>> difference, is that somewhere, there is a changed limiting number for 
>>> script-size stored - thoughts?
>>>
>>> Thanks;
>>> Dave
>>> PS SELINUX restored to "permissive" from "disabled" - _that_ takes a
>>> lot of time!
>>>
>>> Mike wrote:
>>>       
>>>> On July 2, 2009, Dave wrote:
>>>>   
>>>>         
>>>>> A few days ago a bash shell script that had been working reliably
>>>>> for months, suddenly quit working. The script has not been changed.
>>>>>
>>>>> I see no error messages either from cron, or from manual invocation
>>>>> of the script. It's as if I hadn't invoked it.
>>>>>
>>>>> I wrote a trivial test script that works both manually, or via cron
>>>>> (invoked via my crontab entry). But my desired script  produces
>>>>> nothing.
>>>>>
>>>>> Where do I look to see a hint? Nothing in /var/log/cron or
>>>>> /var/log/messages suggests any problem.
>>>>>
>>>>> Given that a shell script will work as demonstrated by my test
>>>>> script (both from a terminal or via cron), why did my desired
>>>>> script suddenly quit working, silently? Has my OS blacklisted it?
>>>>>     
>>>>>           
>>>> Maybe a recent update introduced a script with same name, or
>>>> changes permissions on it.  One of the securty scripts used to
>>>> disable setuid programs. 
>>>>
>>>> Does your trivial script have the same name as the blacklisted one?
>>>> What does ` which blacklisted script `  return 
>>>> What are the permissions on the blacklisted script   ls - l
>>>> blacklisted script
>>>>
>>>>
>>>>   
>>>>         
>>> -- 
>>> OCLUG general discussion list
>>> [email protected]
>>> http://oclug.on.ca/mailman/listinfo/oclug
>>>       
>> -- 
>> OCLUG general discussion list
>> [email protected]
>> http://oclug.on.ca/mailman/listinfo/oclug
>>     
-- 
OCLUG general discussion list
[email protected]
http://oclug.on.ca/mailman/listinfo/oclug