rbulling's blog

Recently while I was working on strengthening the security of an online password reset tool, I ran into an a pair of file permission issues related to SELinux. I've witnessed many system administrators and engineers throw up their hands when they encounter a problem like this, and turn off SELinux policy enforcement, weakening the security posture of the system. Instead of doing that, I added a new SELinux policy to allow just the operations my new application needed.

When writing software for Linux systems, it's often wise to plan on packaging your software using RPM. Having an easily installable package for your software lets you install and maintain your software using a suite of automated tools. Many software developers don't plan on building RPMs from their sources, but instead rely on operating system distribution vendors and third-party enthusiasts to package their software. This is possible thanks to the flexible nature of RPM's build system, but if you plan ahead, you can have your own build scripts produce RPMs, gaining more control over the packaging in the process.

Suppose you are happily coding away, about to finish a new feature on a shiny new product. You attempt to run your code when an ugly exception rears up from the middle of some code that you call, but did not write yourself. You attempt to use your team's version control software to figure out who wrote that code, and what sort of changes have happened to it that might be the source of the problem. Alas, your version control software reveals that Joe, who left the project months ago, wrote the code throwing the exception.