1. 7

Nice approach - walks through the solutions of some well-chosen, relatable problems to explain how linux can make life easier.

  1.  

  2. 4

    I’m a little nervous reading #4a: User/Pass management.

    The example given is

    $ sudo userpass -a foosite -u userbar -p hunter2 -m Foo
    

    Unfortunately, all of that is saved in .bash_history so it doesn’t matter who owns the final file that gets written out. A bad guy just needs to history | grep userpass

    1. 1

      Yep – this is yet another case where I think a “low quality”, “bad advice”, or just plain “I don’t like this” downvote option is sorely needed.

      1. 2

        I few notes though: The scripts in the article were mostly of the “scratch-an-itch” variant, and not a “everyone should be using this”. The title reflects this with “Why I love linux”, and not “8 Awesomes Scripts that Will Make you Love Linux” :)

        Also, the problem .bash_history is the smallest issue of them all. To access this file, you need to have access level of the user, or root. At that point, I’d be already pretty fucked. http://xkcd.com/1200/

        The bigger issue, would be other users on the system monitoring /proc/*/cmdline

        The first can be resolved by enabling HISTCONTROL=ignorespace, and starting commands you want to hide from the history with a prefix space. To avoid both problems, replace the input of the password with (read -s -p “Password: ” password).

        Secondly, and more gravely. Is if someone were to use this on a laptop they carry around with them, and lose it. Anyone can read the file by booting up a LiveCD OS, and accessing the disk contents. For this, the password file should be encrypted, and decrypted on the fly.

        Even better, would be to use something like http://www.passwordstore.org/ instead. For my needs, on a stationary laptop, with a single user, and no mean people to worry about roaming about. It is secure enough.

        Anyway. I’m sorry you found it low quality. It was never my intention for it to pretense as a beacon of excellent code and scripts.

        Cheers.

        1. 1

          Yes, passwords-in-command-line-arguments is a pretty bad idea, as is unencrypted password storage.

          However, also squarely in the bad-ideas category is storing passwords (even encrypted) in a file whose name identifies exactly what system or service it’s for (have all the recent NSA revelations taught us nothing about metadata?). Unfortunately, doing exactly that seems to be a central design element of that program (‘pass’). I really wish people would stop recommending it; it’s just not at all well-designed.