Running a process as a different user…

I’ve been doing a lot with configuration management lately. At work, I’ve used Chef to set up virtual machines on Amazon Web Services, and I’ve used Ansible at home to create and manage the configuration of my laptop and desktop. Both of these tools let you execute commands as different users than the one that invoked the original script. There are lots of reasons to do this, and it’s a great feature.

At the moment, I’m writing some custom Perl scripts, and I find that I also need to execute some commands as a different user.

So, by inspecting Ansible’s source code, I found that it just uses “sudo”. I figured Chef’s source code was probably a lot larger, so I asked around on IRC, and some very nice people on the #chef channel on freenode showed me the following links:

• https://github.com/opscode/mixlib-shellout/blob/master/lib/mixlib/shellout/unix.rb#L124-L125
• http://brizzled.clapper.org/blog/2011/01/01/running-a-ruby-block-as-another-user/

Rather than using sudo, Chef directly changes the EUID and UID of the process it’s running using the Ruby “Process” module.

A few nights ago, before I learned about how Chef handles it, I was reading about how to do this in Python and found “setuid” and “seteuid” with the Python “os” module.

In Perl, there are lots of ways to do it! If we look at http://perldoc.perl.org/perlvar.html, we’ll see that we can use “$<” and “$>” to change the UID and EUID respectively. That’s not very pretty though… so if you use the “English” module, you can refer to them as “$REAL_USER_ID” and “$EFFECTIVE_USER_ID” or “$UID” and “$EUID”. Or… you can use the “POSIX” module’s “setuid” method which will change both at once.

Cool, eh?

In my case, “sudo” would probably be fine, especially as it should take care of things like changing the group ID, the home directory, etc.

---

But let’s assume that we want to change the UID and EUID manually in our process. We won’t necessarily know what UID we want to use. We might just have a username. In that case, we can avail ourselves of Perl’s “getpwnam” function.

So let’s take a look at the documentation:

• http://perldoc.perl.org/functions/getpwnam.html

Well, that’s a bit sparse. Here are some alternatives:

• http://www.tutorialspoint.com/perl/perl_getpwnam.htm
• perldoc -f getpwnam

So all we need is ‘my $uid = getpwnam(“postgres”);’
Then we can do something like ‘POSIX::setuid($uid);’ to change the UID and EUID of the current process!

Figuring out if your computer is 32-bit or 64-bit!

So many of you might have Googled this before and figured that “lscpu” and “uname -a” will tell you whether your computer is 32-bit or 64-bit.

Well, it appears that this is wrong.

When I run “lscpu”, I get “Architecture: i686” (i.e. 32-bit) rather than “Architecture: x86_64” (i.e. 64-bit). Same goes when I run “uname -a”.

Well, that’s because that’s telling me that I’m running a 32-bit OS. I was very green when I first installed Debian on this computer years ago, so I went with the safe bet, since a 64-bit machine can handle a 32-bit OS, while a 32-bit machine can’t handle a 64-bit OS. But I was looking to upgrade to Ubuntu 14.04, and I started wondering… what is my machine really?

So I read through http://unix.stackexchange.com/questions/77718/32-bit-64-bit-cpu-op-mode-on-linux and it actually helped heaps!

I ran the following two commands:

“sudo apt-get install lshw”

“sudo lshw -class cpu”

This printed off heaps of information which includes in the “capabilities: x86-64” and “width: 64 bits”.

Running “grep -w lm /proc/cpuinfo –color” will also show you a flag of “lm” or “Long mode”, which signals the cpu can handle 64 bits.

Now that I’ve learned that, I’m going to stop using Debian 7 Wheezy 32-bit and change over to Ubuntu 14.04.1 LTS 64-bit!