[Solved]Module Activation/Deactivation Start - Stop Scripts.

New features which should be implemented in Porteus; suggestions are welcome. All questions or problems with testing releases (alpha, beta, or rc) should go in their relevant thread here, rather than the Bug Reports section.
Post Reply
User avatar
pumbaa2
White ninja
White ninja
Posts: 29
Joined: 08 May 2012, 10:39
Distribution: Slackware 13.37
Location: Melbourne, FL
Contact:

[Solved]Module Activation/Deactivation Start - Stop Scripts.

Post#1 by pumbaa2 » 11 May 2012, 10:01

Just a thought...

modules should have a special folder that can be removed from the "Live Filesystem" after execution like Slackware's /install/do-inst.sh script in order to bring up or take down services and perform cleanup when a module is activated or deactivated. For instance, it would be BAD to deactivate the nfs-utils module without first umount -t nfs -a. Apache Webserver should stop itself before the module is deactivated or Apache would crash ultimately because its files went missing in the blink of an eye. Apache should start if that module is included for activation during startup or is activated manually. The script could be ran directly from the modules mountpoint to ensure conflicts in filenames, etc don't occur. Once mounted the folder would be rm -rf'ed from the live filesystem side hiding the startup scripts but of course they are still accessible from the module mountpoint which is where activate and deactivate would run them from. The folder could be deep in the system anyway and would likely be proper to put in something like "/etc/rc.d/rc.live" subfolder with "startmodule" and "stopmodule" as the "executable" names. I didn't include .sh because that file could be ANY executable file including a ELF Binary that might handle first time setup of the module if certain configuration files on the live system were missing indicating that was the first time the module has ever been activated. This procedure should take place for modules placed in /modules subfolder and could be ignored for modules residing in the /base subfolder as these modules construct the main system, libraries, access to shell interpreters, etc. Even if the module stopped the module loader during startup in order to ask questions, you can very easily answer those questions or interact with whatever ncurses interface or shell script interface that comes from running startmodule and it detected a first time run after which the script, ELF or NCurses interface would end and the module activation script during startup would resume...

At the current moment the only way to ensure start of service is to include the rc file in something like /etc/rc.d/rc3.d, but that would only execute if the module was activated at startup time, not if the module is started manually. So far I've yet to see a Live Distro based on this system that implements such a plan (Slax or what have you)... However, I think it is needed to prevent problems in certain instances. Older modules not implementing the code would simply be activated and no startup or stop script is executed. My only complaint is this could open a small security hole. As module activation is ran as root the shell script, ELF Binary, etc would be ran as root which could lead to a module that could literally destroy the system. A "cheatcode" could be implemented to prevent module startup actions from being executed. But really this isn't any worse than using any other module as a bad module could be constructed to autostart if it put the right RC File in place during mount causing execution during startup anyway which once again gets run as root.

For further security, modules that aren't +x shouldn't mount and become apart of the live filesystem. I realize the flag is used for executing files but since we don't execute modules, we can simply +x or -x the modules and leave them in the modules folder but only modules that are +x would activate on startup. This method wouldn't affect manual activation from the command line... Testing a file to see if it has execute permissions is easy as pie... There are MANY examples of it in /etc/rc.d/rc.M...

Posted after 22 minutes 30 seconds:
Keep in mind this could also be used to optimize module activation... At the moment the activate runs a set of commands to ensure libraries, KDE Application Menus, etc get put in place... However, not all applications will have a place in KDE or have libraries associated.. To overcome this issue simply use "flag" files. if /etc/rc.d/rc.live/run-ldconfig (which is 0 bytes) exists, then the module has libraries and needs ldconfig ran to ensure proper access. During startup you mount all modules first, then check the live filesystem directory instead of the module directory. If even 1 module has /etc/rc.d/rc.livfe/run-ldconfig it will show up on the live filesystem. Same if 4 modules have that file. But if none of them do then the file will be missing on the live filesystem. Modules that are completely missing /etc/rc.d/rc.live directory should follow the old rules and just run everything to ensure what needed to be done, got done. Once again performing cleanup by rm -rf /etc/rc.d/rc.live from the Live Filesystem.
Last edited by pumbaa2 on 13 May 2012, 12:21, edited 1 time in total.

User avatar
fanthom
Site Admin
Site Admin
Posts: 4613
Joined: 28 Dec 2010, 02:42
Distribution: Porteus Kiosk
Location: Poland, currently - Cork, IE
Contact:

Re: Module Activation/Deactivation Startup - Stop Scripts.

Post#2 by fanthom » 11 May 2012, 12:25

hello pumbaa2 and thanks for your suggestions,
Even if the module stopped the module loader during startup in order to ask questions, you can very easily answer those questions or interact with whatever ncurses interface or shell script interface that comes from running startmodule and it detected a first time run after which the script, ELF or NCurses interface would end and the module activation script during startup would resume...
i have installed many slackware packages and never seen a case when i would be asked for something. please provide an example.
At the current moment the only way to ensure start of service is to include the rc file in something like /etc/rc.d/rc3.d, but that would only execute if the module was activated at startup time, not if the module is started manually.
this statement is wrong. i have prepared a simple test.xzm module:
link
which creates a /tmp/test-success file during activation and deletes it during deactivation - please try it yourself.
A "cheatcode" could be implemented to prevent module startup actions from being executed. But really this isn't any worse than using any other module as a bad module could be constructed to autostart if it put the right RC File in place during mount causing execution during startup anyway which once again gets run as root.
exaclty. we had a longer discussion with security subject in this thread:
link
conclusion: there is no way of preventing hackers of smuggling and executing malicious code placed inside the modules.
trusted repos are the only way of minimizing the risk (same applies to slackware .txz packages and doinst.sh scripts)
For further security, modules that aren't +x shouldn't mount and become apart of the live filesystem.
porteus is able to run from non-posix filesystems (Fat is still the most popular on removable media) so this check is of no use here.
Keep in mind this could also be used to optimize module activation...
yep - but in some cases modules comes with really poor quality and i see no way of forcing users to create them in a "proper way".
i think it's better to sacrifice 2-3 seconds (for updating caches even when it's not necessary) than to get complaints about non working modules.
i could implement a check for /etc/rc.d/rc.live to speed up injections of modules created by experienced users. but i think it's a lot of manual work (64bit repo has over 500 modules at the moment) with a little gain - let's check what others think.

Cheers
Please add [Solved] to your thread title if the solution was found.

User avatar
pumbaa2
White ninja
White ninja
Posts: 29
Joined: 08 May 2012, 10:39
Distribution: Slackware 13.37
Location: Melbourne, FL
Contact:

Re: Module Activation/Deactivation Startup - Stop Scripts.

Post#3 by pumbaa2 » 12 May 2012, 10:41

Heh, this is what happens when I open my mouth before reviewing the code to the activate/deactivate scripts. I take it, any file created in the filesystem that is +x and inside /etc/rc.d/ would be executed on activation/deactivation or does the fact that the file is called rc.test reside because the module itself is called test?

As far as questions during module activation. For the most part Slackware modules are pre-configured to some default that will allow it to function, but this isn't always the best plan. For instance Porteus is configured for user root and toor for the password, or guest/guest. However the Porteus core component module could check to see if the password has ever been changed (by checking the password hash in /etc/shadow for root against a known source in the script) and ask to set a password during boot but bypass the request if the "changes" variable is left blank meaning use memory. This also goes for Timezone information, hostname, etc. However, this isn't the best example.

This one is better and real world. Webmin (a Perl Administration Panel for Linux) is copied to your hard disk in a folder like /usr/webmin and then the install script it kicked off. This script asks questions like what port number should it run on, whats the default account name/password... What version of linux are you running (We detected Slackware 13.37). Of course I'm aware you could configure it for default 10000 with root/toor as the userid/password but that in itself opens its own security hole. Also since the module was created on say "Slackware 13.37" what is to say I didn't use that module for 13.57 (some future release because a new version of webmin hasn't been posted to the repo), well it would be incorrectly configured then. Also, If people are forced to set the password and port number, they have no choice and they will, otherwise the module won't start service or the module will deactivate itself. But if the package comes pre-configured, the average person will just use that and never change it. Eventually a "hacker" (cough, cough) will hack their webmin and their system will go away. "Packages" like webmin are designed to be configured on first startup, there is no checker in webmin to see if the account password has been changed from toor and force them to change it from inside webmin because its expected that the installer script took care of this.

However, consider this... If a module is going to cause destruction *IT WILL*... Core is mounted way before any user modules. If I decided to replace /bin/bash with a virus it would DEFINITELY run on startup when the first startup script is called, or when the user logs in, etc... It could also hide its actions by calling some daemon and then wrapping the command line args to the real bash and creating the shell the user was expecting. But also consider that we are a community bent on making the computer world easier and better for everyone, not some VBS Script lamer distributing .vbs scripts as "Mp3's" on systems like Limewire waiting for the next victim to run it thinking it will play a pretty little tune that decides to open a backdoor and crash their computer instead. We do this because we enjoy what we do, not because we are being paid by "The Beast" to write bloated commercial software that runs vbs scripts and works part of the time (cough cough).

In conclusion, we have to trust the linux community. That trust is bigger than the average person might imagine, because if it wasn't for that trust, we'd have kernels with backdoors, distributions with secret logins, etc. We just have to test modules before putting them on the repo or at least get the update from a source that you KNOW isn't going to do something of that nature. My trust in the linux community FAR exceeds the average lamer on the internet performing port scans on port 10000 looking for the next linux user who forgot to change their password for webmin because they forgot and the package/module never asked. Just add a disclaimer "README" in the modules folder that is ignored by the startup scripts of course with text saying they should never activate modules from 3rd parties, etc as they may harm their computer. We have no liability, etc, etc. This is no different than what Google does on Android Phones.

In regards to +x on modules. I keep forgetting this is a Pendrive Distro as I've been able to make it do whatever I've asked of it. I was amazed that after I created a module for QT-4.6.2 and libcdaudio-0.99.12p2 that I was able to compile MythTV without any issues. However, files are FAT Filesystems are all +x, so doing this check wouldn't hurt anything, they just couldn't deactivate the modules during boot for FAT Installs in which cause the old rules apply, remove the module from the modules directory. To me its just easier to look at the modules directory like looking at /etc/rc.d. If the file isn't +x, the service won't start. This is very optional though and just wanted to toss it into the pool of simplifying things.

User avatar
fanthom
Site Admin
Site Admin
Posts: 4613
Joined: 28 Dec 2010, 02:42
Distribution: Porteus Kiosk
Location: Poland, currently - Cork, IE
Contact:

Re: Module Activation/Deactivation Startup - Stop Scripts.

Post#4 by fanthom » 12 May 2012, 13:10

I take it, any file created in the filesystem that is +x and inside /etc/rc.d/ would be executed on activation/deactivation or does the fact that the file is called rc.test reside because the module itself is called test?
this is the code from activation script:

Code: Select all

# Find and run all rc scripts from the module
for SCRIPT in `find $MOD/etc/rc.d $MOD/etc/init.d $MOD/etc/rc.d/init.d -type f -maxdepth 1 2>/dev/null | sed s^$MOD^^ | sort -u`; do
    [ -x "$SCRIPT" ] && $SCRIPT start
done
every executable file placed inside the module ($MOD variable) in /etc/rc.d or /etc/init.d or /etc/rc.d/init.d is executed just after activation with "start" argument (ofc it's "stop" for deactivate).
the Porteus core component module could check to see if the password has ever been changed (by checking the password hash in /etc/shadow for root against a known source in the script) and ask to set a password during boot but bypass the request if the "changes" variable is left blank meaning use memory.
tried that in the past and nobody liked an extra stop during boot. wiped off so...
Webmin (a Perl Administration Panel for Linux) is copied to your hard disk in a folder like /usr/webmin and then the install script it kicked off. This script asks questions like what port number should it run on, whats the default account name/password...
yes - but as my point above: nobody likes an extra stops during boot. if user wants to use webmin in porteus then it's better when he creates xzm module containing his own unique settings himself.
i want to keep things simple and would like to avoid adding exceptions for every non standard module which is used by a very few people.
If a module is going to cause destruction *IT WILL*...
no doubts about it
In conclusion, we have to trust the linux community.
that's also my point from the thread linked in my previous post.
However, files are FAT Filesystems are all +x, so doing this check wouldn't hurt anything, they just couldn't deactivate the modules during boot for FAT Installs in which cause the old rules apply, remove the module from the modules directory. To me its just easier to look at the modules directory like looking at /etc/rc.d. If the file isn't +x, the service won't start.
we have /porteus/modules and /porteus/optional folders for that purpose. if you dont want to activate a module during startup then just move it to /porteus/optional. this method works for FAT and is straight forward even for new users (try ask a windows newbie what -x bit is).
please also have a look on 'load=' and 'noload=' cheatcodes which are giving even more flexibility in term of activating (or not activating) modules during startup. i really dont think we could improve anything in this subject...

Cheers
Please add [Solved] to your thread title if the solution was found.

User avatar
pumbaa2
White ninja
White ninja
Posts: 29
Joined: 08 May 2012, 10:39
Distribution: Slackware 13.37
Location: Melbourne, FL
Contact:

Re: Module Activation/Deactivation Startup - Stop Scripts.

Post#5 by pumbaa2 » 13 May 2012, 07:15

Okay... But just as a note, the rc startup script is executed before performing cache updates which may result in a failure of the service to come up. I would honestly reverse that order in order to prevent such a problem. Just me thinking ahead... :)

User avatar
fanthom
Site Admin
Site Admin
Posts: 4613
Joined: 28 Dec 2010, 02:42
Distribution: Porteus Kiosk
Location: Poland, currently - Cork, IE
Contact:

Re: Module Activation/Deactivation Startup - Stop Scripts.

Post#6 by fanthom » 13 May 2012, 08:15

nice catch :)
moved down and also added another check for immodules in case when user want's to have multiple gtk+ versions in the system (gtk3 needs it for sure):

Code: Select all

gtk=`ls $MOD/usr/lib/gtk*/*/immodules/ 2>/dev/null | wc -l`
if [ $gtk -gt 0 ]; then
    echo "Updating GTK immodules: /usr/bin/update-gtk-immodules"
    /usr/bin/update-gtk-immodules
fi
Please add [Solved] to your thread title if the solution was found.

User avatar
pumbaa2
White ninja
White ninja
Posts: 29
Joined: 08 May 2012, 10:39
Distribution: Slackware 13.37
Location: Melbourne, FL
Contact:

[Solved] Module Activation/Deactivation Startup - Stop Scrip

Post#7 by pumbaa2 » 13 May 2012, 12:20

solving Thread... Thanks for all your help. :D

Post Reply