May 2013
M T W T F S S
« Apr    
 12345
6789101112
13141516171819
20212223242526
2728293031  
101

Refs

Categories

Archives

9,331slm
●5 ●38 ●132
 

How does a process deal with user credentials?

Background

A question came up on the Stack Exchange site Unix & Linux in which I wrote up a pretty good answer, that describes some of the mechanics of how a process deals with its user credentials, so I’m adding my writeup to the blog.

It really comes down to what makes up a process in Unix. A process can come into existence in one of 2 ways. Either via the fork() function or through one of the exec() functions in C.

fork()

fork() basically just makes a copy of the current process, but assigns it a new process ID (PID). It’s a child of the original process. You can see this relationship in the output of @ps@:

1
2
3
4
5
6
7
$ ps axjf
 PPID   PID  PGID   SID TTY      TPGID STAT   UID   TIME COMMAND
    1  5255  1964  1964 ?           -1 Sl     500   0:39 gnome-terminal
 5255  5259  1964  1964 ?           -1 S      500   0:00  \_ gnome-pty-helper
 5255 18422 18422 18422 pts/1    18422 Ss+    500   0:01  \_ bash
 5255 30473 30473 30473 pts/4    30473 Ss+    500   0:00  \_ bash
30473   782   782 30473 pts/4    30473 Sl     500   1:14  |   \_ evince s.pdf

Here you can see that gnome-terminal is the parent process (PID = 5255) and that bash is it’s child (PID = 18422, PPID = 5255).

When a process forks from its parent, it “inherits” certain things, such as copies of all the file descriptors that the parent currently has for open files and the parent’s user and group IDs.

NOTE1: PPID = Parent Process ID.
NOTE2: The last 2 are what identify what file and group permissions this process will have when accessing the file system.

So if a process just inherits its user and group ID from its parent, then why isn’t everything just owned by root or a single user? This is where exec() comes in.

exec() Part #1


…. Continue reading → How does a process deal with user credentials? »»

How is my password stored in Linux?

Background

People that use Linux on a daily basis probably are completely oblivious to the actual mechanisms being used to store their passwords safely and securely on a given Linux system. Oh they might guess that their password is stored in the /etc/passwd file (they’d be wrong by the way) but most probably never even gave it a passing thought. So I thought I’d take the opportunity to shed some light on how Linux systems “stash” your precious password away.

Solution

So if your password isn’t actually stored in the /etc/passwd file then where does it get stored?

Answer: the /etc/shadow file.

This file is where all the keys to each user’s account are kept for safe keeping. Obviously only the root user can peer inside this file so all the commands we’ll be dealing with in this post, it should be assumed that you’ll need to either be root, or use sudo to run.

/etc/shadow

A typical /etc/shadow entry:

1
root:$6$bbmDJwcZHy5bgEDz$kFO.W/T7nUqcszZWl5RglxoDDAcDxevWpHVfN3v3f.Cx2ZeMcn5PX23VvnnkgtNWZf8hYtqsL0pPkZqyj50NY/:14362:0:33333:7:::

NOTE1: Don’t get too excited, the above isn’t really my entry, I made this one up.
NOTE2: Each field is separated by a colon (:) & we’re only concerned with the first two columns!

dissecting the hash

The key pieces to notice in that line of what looks like gibberish is the following:

  • The first column, root is the user whom this entry belongs to from the /etc/passwd file.
  • The second column, $6$..... is essentially the user’s hashed password.

Taking the second column apart further you should start to notice that’s it’s not complete gibberish after all.

For example:

  • the first couple of characters, $6$, is a mark that tells the system what type of hashing was used to hash the password.
  • The text between the next set of dollar signs, $bbmDJwcZHy5bgEDz$, is the actual salt that was used to hash your password.
  • Everything else after, is your password + salt hashed using whatever hash function was specified at the beginning, $6$, in our example here.

Specifically if you look at the man page for the crypt command, man 3 crypt there is a section that discusses what the $6$ notation means:

So $5$salt$encrypted is an SHA-256 encoded password and $6$salt$encrypted is an SHA-512 encoded one.

NOTE: So in our case the password + salt is being hashed using the SHA-512 scheme.

design details


…. Continue reading → How is my password stored in Linux? »»

How to rsync certain files, exclude the rest, all while ignoring .svn directories?

I came across this question on the Stack Exchange site Unix & Linux. The question interested me so I answered it but thought I’d cross post it on my blog as well, given I took a pretty significant amount of time to put together a test case and write-up of how the solution ultimately worked.

Problem

I’m using rsync to copy some files from a share to another.

Recursively, I need to:

- delete files at the destination that are deleted in the origin
- Only sync php and js files
- exclude de rest of file types
- Don’t delete .svn/ directory in the destination

If I use this:

rsync -zavC --delete --include='*.php' --include='*.js' --exclude="*" /media/datacod/Test/ /home/lucas/Desktop/rsync/

Then rsync is not recursive because exclude=”*” excludes all files but also folders

If I add --include="*/" then the .svn/ directory gets deleted (it also gets included)

How can I solve this mind blasting dilemma?

Solution

The solution I ultimately came up with made use of a little known feature, at least to me, called filters. Filters allow you to play games with the includes/excludes by protecting portions based on regular expressions. Read on, I’ll discuss them further down.

1
2
rsync -avzC --filter='-rs_*/.svn*' --include="*/" --include='*.js' --include='*.php' \
     --exclude="*" --delete dir1/ dir2/

test data

To help determine if my solution was going to work or not I created some sample data so that I could test it out. For starters I wrote a script that would generate the data. Here’s that script, setup_svn_sample.bash:


…. Continue reading → How to rsync certain files, exclude the rest, all while ignoring .svn directories? »»

[one-liner]: Dealing with UEFI

Background

UEFI looks to be a major pain in the @$$, but like it or hate it everyone in the Linux community will need to learn to navigate it. Here’s a list of useful UEFI resources that I’ve come across as I’ve started to get smarter about how to deal with this beast.

Solution

Wikipedia

Ubuntu Docs

AskUbuntu

Rodsbooks.com

Misc.

NOTE: For further details regarding my one-liner blog posts, check out my one-liner style guide primer.

[one-liner]: Debugging Bash Scripts

Background

From time to time it’s useful if you can turn up the debugging messages that come from Bash, when working out either interactive or shell script problems. Here are 2 methods that can help in getting down to the details.

Solution

There are essentially 2 methods.

Method #1: -x method

When writing a shell script you’ll sometimes want to turn on line by line debugging. There’s basically 2 ways to to this.

Before we get started, suppose we have this sample script, myscript.bash:

1
2
3
4
#!/bin/bash
 
echo "hi"
echo "bye"

First you can run your script like so:

1
2
3
4
5
% bash -x myscript.bash
+ echo hi
hi
+ echo bye
bye

As an alternative you can add the following line, set -x to the top of our shell script to enable debugging as well:

1
2
3
4
5
#!/bin/bash
 
set -x
echo "hi"
echo "bye"
1
2
3
4
5
% ./myscript.bash
+ echo hi
hi
+ echo bye
bye
Method #2: env SHELLOPTS=xtrace …

This approach sets the env. variable SHELLOPTS=xtrace which has the same effect as using bash -x.

For example:

1
2
3
4
5
% env SHELLOPTS=xtrace ./myscript.bash 
+ echo hi
hi
+ echo bye
bye

You can also use this technique to debug your bash environment (think .bashrc and .bash_profile) like so:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
% env SHELLOPTS=xtrace bash
...
...
+++++ line='complete -f -X
'\''!*.@(zip|[ejw]ar|exe|pk3|wsz|zargo|xpi|sxw|o[tx]t|od[fgpst]|epub|apk)'\''
unzip zipinfo'
+++++ line=' unzip zipinfo'
+++++ list=("${list[@]}" $line)
+++++ read line
+++++ '[' 'complete -f -X '\''*.Z'\'' compress znew' '!=' 'complete -f
-X '\''*.Z'\'' compress znew' ']'
+++++ line='complete -f -X '\''*.Z'\'' compress znew'
+++++ line='complete -f -X '\''*.Z'\'' compress znew'
+++++ line=' compress znew'
+++++ list=("${list[@]}" $line)
+++++ read line
+++++ '[' ' zcmp, zdiff, z*grep, zless, zmore intentionally not here,
see Debian: #455510' '!=' '# zcmp, zdiff, z*grep, zless, zmore
intentionally not here, see Debian: #455510' ']'
...
...

Here you can see every command getting executed from the system and user’s .bashrc and .bash_profile as bash starts up.

NOTE: For further details regarding my one-liner blog posts, check out my one-liner style guide primer.

[one-liner]: Why is Conky reporting a lower CPU frequency, when my CPU frequency is actually much higher?

Background

If you’ve every dealt with Conky you may have gotten a little confused when you’re trying to get it to display your CPU frequency like so:

1
${freq_g cpu0} Ghz

… and Conky is reporting your CPU frequency as 1.12GHz when in fact it’s actually much higher than that, say 2.67GHz. Most likely this is being caused by the CPU governing features that are present in most modern hardware. Here’s a behind the scenes 5 second tour of seeing what’s going on within your Linux Kernel.

Solution

First, from the conky man page.

cpu (cpuN)

CPU usage in percents. For SMP machines, the CPU number can
be provided as an argument. ${cpu cpu0} is the total usage, and ${cpu
cpuX} (X >= 1) are individual CPUs.

freq_g (n)

Returns CPU #n’s frequency in GHz. CPUs are counted from 1.
If omitted, the parameter defaults to 1.

You most likely have something like SpeedStep enabled which is acting like a governor on a car, regulating the speed of the cores inside your CPU. You can confirm that this is going on by looking at the output of this command:

1
2
3
4
5
6
7
8
9
% less /proc/cpuinfo
processor       : 0
vendor_id       : GenuineIntel
cpu family      : 6
model           : 37
model name      : Intel(R) Core(TM) i5 CPU       M 560  @ 2.67GHz
stepping        : 5
cpu MHz         : 1199.000
...

The 2 numbers that matter are the 2.67GHz, that the GHz that my CPU is rated to operate at followed by the number 1199.00, this is what my CPU is allowed to run at by the governor setup on my Linux laptop.

You can see what governor is currently configured like so:


…. Continue reading → [one-liner]: Why is Conky reporting a lower CPU frequency, when my CPU frequency is actually much higher? »»

Page 1 of 3312345...102030...Last »