Tag: Command-line interface

  • The sudo tty bug and procps

    There have been recent reports of a security bug in sudo (CVE-2017-1000367) where you can fool sudo into thinking what controlling terminal it is running on to bypass its security checks.  One of the first things I thought of was, is procps vulnerable to the same bug? Sure, it wouldn’t be a security bypass, but it would be a normal sort of bug. A lot of programs  in procps have a concept of a controlling terminal, or the TTY field for either viewing or filtering, could they be fooled into thinking the process had a different controlling terminal?

    Was I going to be in the same pickle as the sudo maintainers? The meat between the stat parsing sandwich? Can I find any more puns related somehow to the XKCD comic?

    TLDR: No.

    (more…)
  • pidof lost a shell

    pidof is a program that reports the PID of a process that has the given command line. It has an option x which means “scripts too”. The idea behind this is if you have a shell script it will find it. Recently there was an issue raised saying pidof was not finding a shell script. Trying it out, pidof indeed could not find the sample script but found other scripts, what was going on?

    (more…)

  • psmisc 22.14 Released

    The upstream and Debian packages for psmisc version 22.14 were released tonight.  This version has a lot of bugfixes.  I’ve also taken some time to clean up some of the minor compile warnings I used to get which were mainly variables set but not used.

    Two bugs that I’ll concentrate on getting fixed for the next version are all about the command line.

    The first is that the fuser -s flag changes the return code for items found.  It should be consistent so it doesnt matter if fuser displays values or not, 0 means found something and 1 means didn’t find it. I can see why in the code it might be different, because the code follows different paths with the s option, but not exactly where the problem is.

    The second bug is the -M flag for fuser only works if it is before the mount points so -M -m /foo works but -m /foo -M does not.  Unlike the -s problem, I can see where it is failing.  Currently fuser scans the options one by one.  If it finds a -m option, it checks at that point if the -M option is set.  The solution is to store all potential targets and only after exhausting the entire command line do we add the potential targets  to our “real” targets.  It means scanning the command line, or a subset of it, twice but the performance penalty is tiny.

    Finally, I released there was a rather neat Makefile command “make distcheck”. This target makes a tar.g archive, extracts it, builds then cleans.  It is a very good program for trapping things like a file exists in your local directory but is not included in the tar.gz (lists.h was missing until I ran this).  For some “make distcheck” is something they’re known for years, but if you have an autotools package you develop, have a look at it.

    With all the talk about testing and test driven releases, I was going to put some test cases in. The problem is there doesn’t seem to be an easy way to do testing. I might have to just hack up some scripts but surely there is a better way. That would trap, for example that fuser -s returns 1 but fuser returns 0.  I looked at check, but it doesn’t work for single-file programs like psmisc is mainly made of.

    Enhanced by Zemanta