Showing posts with label scripting. Show all posts
Showing posts with label scripting. Show all posts

Monday, August 1, 2011

User owned scripts security

Since I am posting scripts (bash, pythong, ect.) up here, I figure it would be a good idea to mention security and permissions of these (or any of you own/other's) scripts.  If you make a script executable (chmod +x scriptname), Linux can use the shebang to determine the script type, and run with a call similar to any other application on the system.  However, if like me you care about security, you may not want to have executable files in your home directory.  One of the best things about linux (or any *nix including bsd, or mac) is the user permissions management.  If your account gets compromised, that doesn't mean the rest of your whole system has been "rooted" (compromised as the root user).  Most infections (linux is not immune to compromise) attack executable files that your user has access to, and so if you have executable scripts in your home directory, they can be written to.  Then the next time you call on one of these scripts, you may be running a malicious hacker's code.

Now you may ask “what alternative is there?”.  With the rest of this post, I plan to give a few.

root owned (standard for most systems):
If it is a script that others on the system would want to use (and you can become root), you could move it into one of the system folder in the users $PATH.  I don't tend to do this often (and dont really suggest it), since it puts random scripts outside of the system's package management.  Instead it may be best to use one (or a combination like I do) of the following options. You can then give the other users the file (use links, edit their rc files (~/.bashrc, ~/.profile) as root, or include them in /etc/skell before creating the users) .

rc file:
As stated in my previous post, you may create a file with a list of simple functions. If its a simple script, it may be fairly easy to convert to a function (or a few).  If you can create a few functions you would want to use together, include them into an 'rc' file.  Then when you want to use them, you only need to 'source' the file first (source MyFunctions.rc). You can then call on the functions just like any other command. If it is a list of functions you would want to use (or at least be able to without sourcing the file) every time you login, you could include sourcing the rc file through your ~/.bashrc (or ~/.profile if you might want to use these functions as shortcuts in your GUI shell such as gnome. I may go into this further in another post, but thats beyond the scope of this article).

Not every script can easily be converted to the function, and so

alias the complex scripts:
most modern linux distrobutions include a tag in your ~/.bashrc, or .profile to source a ~/.bash_aliases file.  Create, and use this file if you dont already have it. And a statement similar to the following 'if' should be included your ~/.bashrc, or ~/.profile

if [ -f ~/.bash_aliases ]; then
    . ~/.bash_aliases
fi


!!you can use a this as example of sourcing to source one of the previous mentioned functions rc files in your bashrc, or profile.

Create your ~/.bash_aliases file and fill it with statements similar to the following example to create a command to run a non-executable bash script called ~/myscripts/newscript as a command 'myscript'

alias myscript=”bash ~/myscripts/newscript”

your ~/.bashrc file is parsed every time you login to bash, your .profile is sourced every login (including most GUI shells such as gnome, kde, xfce4) so if you have non-executable scripts that use a gui toolkit (such as zenity for gnome) you may want to source another ~/.gui-aliases or similar in your ~/.profile so you can easily run said aliased script through terminal, or a shortcut in your applications menu, panel, or desktop.

Thats about all for this post. I will probably give an example rc file (with some fun included functions) that auto-aliases all scripts under a folder based on the “shebang” line in a future post.

Monday, July 25, 2011

Python Superscript

similar to my last post about bash scripting with "basename" functionality, here is an example python module to determine the name of the link being called as well as the arguments supplied:


#!/usr/bin/env python
#-*- coding:utf-8 -*-

"""
        PROJECT - MODULE:
                Python-SuperScript.py

        DESCRIPTION:
                example basename functionality handling in python

        @copyright: 2011 by nairb <code@nairb.us>
        @license: GNU GPL, see COPYING for details.
"""

import os, sys, string

class App(object):
        """ Class doc """
     
        def __init__ (self):
                """ Class initialiser """
                pass
             
        def progName(self):
                """  Return the program name of running script
                @param: none
                @return: base name of the running script
                """
                argvz=string.split(sys.argv[0], '/')
                return argvz[len(argvz)-1]
             
        def progArgs(self):
                """ Return the array of arguments given
                @param: none
                @return: the arguments passed to script
                """
                return sys.argv[1:]

        def Main(self):
                """ Main Function
                @param PARAM:
                @return RETURN:
                """
                print "This program was called as:\n\t" + str(self.progName()) + "\n\nArguments where passed of:\n\t" + str(self.progArgs())
     
if __name__ == '__main__':
    a=App()
    a.Main()

hope someone finds this useful

Sunday, July 24, 2011

Basename function processing without basename binary installed

OK, so Im going to start posting some howto pages to this blog.

starting with a bash scripting case statement to decide script function based on "basename" (or the name of the file running as the script) without the "basename" binary installed. This way you can create many links to the same script, and make the that script do many different things determined by the link name it is being called as. Then you just need to make sure these links to the script are in a directory somewhere within your $PATH.

example:
case $(echo ${0##*/} |cut -d '/' -f $(echo ${0##*/} |wc -w)) in
    scriptlinkname1)
        echo "doing the function scriptlinkname1"
        ;;
    *)
        echo "did not define that links function yet"
        ;;
esac


hope you find this helpful.