RedHat

You are currently browsing articles tagged RedHat.

Linux file permissions were always intimidating to me, but now I think I have the hang of it.  Let’s take a look at some basic permissions on a file I created…

[root@CentosBox myfolder]# ls -l
total 12
-rw-r–r– 1 root root 15 Jul 12 17:37 myfile1
-rw-r–r– 1 root root 15 Jul 12 17:37 myfile2
-rw-r–r– 1 root root 15 Jul 12 17:37 myfile3

So as you can see, each file has some attributes attached to it.  The attributes are…

rw-r–r– 1 root root 15 Jul 12 17:37 myfile1

The very first character (-) tells you what you are dealing with.  For now, let’s consider it having two options.  A ‘-‘ indication a regular file and a ‘d’ indicates a directory. 

The next block (highlighted in red) are what is considered to be user permissions.  I really prefer to call them the owner permissions though since they only apply to the owner of the file.  The next block (highlighted in green) are the group permissions.  And finally, the last block shows what I call the ‘everyone else’ permissions. 

So each block of permissions contains 3 characters.  The first (r) is the read permission, the second (w) is the write permission, and the third (x) is the execute permission.  If the space where a r,w, or x should be is represented with a ‘-‘ that indicates that there is no permission for that particular item. 

Now after the block of rwx’s come the owner of the file which is an individual user.  Directly after the user comes the group that owns the file.  If you create a file, the user and group will both show your name since you (the user) own it as well as your group (you primary group that only you are a member of).

So let’s take a look at some examples.  I’ve changed the owners on the files as shown below….

Note, it’s no fun to user the root user to test permissions since root has access to everything regardless of permissions. 

[myuser@CentosBox myfolder]$ ls -l
total 16
-rw-r–r– 1 myuser2 myuser2 15 Jul 12 17:37 myfile1
-rw-r–r– 1 myuser  myuser2 15 Jul 12 17:52 myfile2
-rw-r–r– 1 myuser2 mygroup 30 Jul 12 17:53 myfile3
-rw-r–r– 1 myuser  mygroup 15 Jul 12 17:55 myfile4

So if I log into the server as myuser, which files should I be able to change?  The correct answer is myfile2 and myfile4.  Now, if I change the group permissions on all of the files to include ‘write’ what files could I write to?  Let’s see…

[myuser@CentosBox myfolder]$ ls -l
total 16
-rw-rw—- 1 myuser2 myuser2 15 Jul 12 17:37 myfile1
-rw-rw—- 1 myuser  myuser2 15 Jul 12 17:58 myfile2
-rw-rw—- 1 myuser2 mygroup 30 Jul 12 17:53 myfile3
-rw-rw—- 1 myuser  mygroup 15 Jul 12 17:55 myfile4

So now what files could myuser write to?  Correct answer is myfile2, myfile3, and myfile4.  Now let’s do a little further explaining.

The permission get evaluated left to right.  So first it looks to see if Im the owner of the file.  In the case of myfile1 above, I am not (since Im logged in as myuser).  Second it looks at the group permissions.  I am not a member of the myuser2 group (since it’s myuser2’s primary group).  So then it falls back to the ‘everything else’ set of permissions which say I can only read the file. 

In the case of myfile2, Im the owner so I have rw- permissions
In the case of myfile3, Im part of the group so I have rw- permissions
In the case of myfile4, Im the user so I have rw- permissions

Make sense?  Pretty straight forward once you sit down and look at it. 

Tags:

Here’s another one that I really hadn’t heard of before.  In the command shell, there’s the idea of background and foreground processes. 

The example they used in class involved the sleep command, which is sort of lame, but it works.  So if we tell the console to sleep for 60 seconds we’d do something like this…

[root@CentosBox ~]# sleep 60

Now most of us probably know that we can terminate that process (running the foreground) by issuing a CTRL-C command.  If we do that, we get our normal console prompt back and the process dies.  However, if we issue a CTRL-Z we can pause the process…

[root@CentosBox ~]# sleep 60

[1]+  Stopped                 sleep 60
[root@CentosBox ~]#

Now at this point, I can tell the job to run int the background by issuing a ‘bg’ command.  If there were more than one job running I could specify the number.  So in this case it would be ‘bg 1’…

[root@CentosBox ~]# bg 1
[1]+ sleep 60 &
[root@CentosBox ~]# jobs
[1]+  Running                 sleep 60 &
[root@CentosBox ~]#

Then by entering the ‘jobs’ command, we can see that it’s now running again, but I have my console back.  So if you have a big script running, force it into the background so you can keep doing stuff.  Then just check to see when it’s done.  Better yet, you can just tell the command to run in the background to start with by issuing the ‘&’ after the command.  For instance…

[root@CentosBox ~]# sleep 6000 &
[2] 19080
[1]   Done                    sleep 60
[root@CentosBox ~]# sleep 7000 &
[3] 19081
[root@CentosBox ~]# jobs
[2]-  Running                 sleep 6000 &
[3]+  Running                 sleep 7000 &

You can also, kill the jobs if they are running for too long.  Here I show a couple examples of how to kill jobs…

[root@CentosBox ~]# jobs
[2]-  Running                 sleep 6000 &
[3]+  Running                 sleep 7000 &
[root@CentosBox ~]# jobs
[2]-  Running                 sleep 6000 &
[3]+  Running                 sleep 7000 &
[root@CentosBox ~]# kill %2
[root@CentosBox ~]# jobs
[2]-  Terminated              sleep 6000
[3]+  Running                 sleep 7000 &
[root@CentosBox ~]# jobs -l
[3]+ 19081 Running                 sleep 7000 &
[root@CentosBox ~]# kill 19081
[root@CentosBox ~]# jobs
[3]+  Terminated              sleep 7000
[root@CentosBox ~]#

In the first instance, I used the job number (1) and the ‘kill %’ command.  In the second instance, I found the PID by doing a ‘job -l’ and used that with the kill command.

Pretty powerful stuff if you get acquainted with managing processes effectively. 

Tags:

One of the key components of any system are the users and groups.  Linux is no different.  Let’s get right into it. 

The important files
So there are three important files when talking about users and groups.  They are..

/etc/passwd
This file (despite it’s name) stores the locally defined user accounts.  Each line of the file is for a single user.  For instance…

[root@CentosBox etc]# more /etc/passwd | grep test
test_user:x:500:500::/home/test_user:/bin/bash

A line is broken into a couple of fields delimited by a colon.  Here’s what each field is starting from the left..

Username
Place holder
– Used to be the encrypted password
User ID (UID) – User defined users should have a UID thats above 500.  0 is reserved for root and 1-499 are system defined (for daemons etc).
Group ID (GID) – Every user has a ‘primary group’ created for them.  They are the only people that can be a member of this group.  The GID field represents this group.
Comment Field – I guess it’s actually the ‘name’ field in the GUI
Home Directory – The user’s home directory
Login Shell – The user’s login shell

/etc/shadow
This file keeps track of the locally defined user passwords as well as account items related to things like password aging, password expiration, and so on.  A line in the file would look like this…

[root@CentosBox etc]# more /etc/shadow | grep test_user
test_user:$1$/6caNEpK$C4Xo005ZQ3FckzMDwTmc31:15532:0:99999:7:::

The first field shows the user name.  The second field is related to account status.  For instance, if I create an account and don’t set the passwords it will show as $!!$.  If I lock the account, it might shows as $!$.  Seems that if everything is in order it looks like $1$.  The third field is the encrypted password.  And the forth field is really another set of colon delimited integers.  These, relate to the aforementioned account settings.  These can be set/read with the ‘chage’ command…

[root@CentosBox etc]# chage -l test_user
Last password change                                    : Jul 11, 2012
Password expires                                        : never
Password inactive                                       : never
Account expires                                         : never
Minimum number of days between password change          : 0
Maximum number of days between password change          : 99999
Number of days of warning before password expires       : 7

/etc/group
This file keeps track of the locally defined groups and their members.  Again, it’s pretty straight forward.  Here I created a group called ‘test’ and added two users to it (test_user and test_user2).

[root@CentosBox etc]# more /etc/group | grep test
test_user:x:500:
test:x:501:test_user2,test_user
test_user2:x:502:

Note that the grep returned the primary group numbers for each of the users as well.  The group ‘test’ has a secondary group ID of 501 and has members test_user2 and test_user in it.  The second field (shown as an X) is described as ‘password’.  Not sure what the deal with that is though.

Other useful commands for users and groups
o let’s imagine that I just created the test_user user (which I did by the way).  I would have done something like this…

[root@CentosBox etc]# useradd test_user

That’s it.  The only other thing I have to do is to set the user’s password.  This is done with the ‘passwd’ command. 

[root@CentosBox etc]# passwd test_user
Changing password for user test_user.
New UNIX password:
BAD PASSWORD: it is based on a dictionary word
Retype new UNIX password:
passwd: all authentication tokens updated successfully.

Now the account is ready to use.  what if we wanted to add the user to a group through?  That’s done with the ‘usermod’ tool.  We’d do something like this…

[root@CentosBox etc]# usermod -aG test test_user

Make SURE you include the -a flag in the usermod command.  The ‘a’ stands for append, and without it, you are removing the user from any previously defined group they were in. 

We can also user usermod to lock and unlock accounts with the ‘L’ and ‘U’ flags. 

[root@CentosBox etc]# usermod -L test_user
[root@CentosBox etc]# passwd -S test_user
test_user LK 2012-07-10 0 99999 7 -1 (Password locked.)
[root@CentosBox etc]# usermod -U test_user
[root@CentosBox etc]# passwd -S test_user
test_user PS 2012-07-10 0 99999 7 -1 (Password set, MD5 crypt.)

Also, if you ever want a quick run down on a user, use the ‘id’ command.

[root@CentosBox etc]# id root
uid=0(root) gid=0(root) groups=0(root),1(bin),2(daemon),3(sys),4(adm),6(disk),10(wheel),500(AwesomeRootGroup)

This tells us the user ID, the primary group ID, and which groups the user is in.

Now let’s say I want to clean all of this up.  Easy, just use the ‘userdel’ and ‘groupdel’ commands. 

[root@CentosBox etc]# groupdel test
[root@CentosBox etc]# userdel -r test_user
[root@CentosBox etc]# userdel -r test_user2

The -r flag tells the command to cleanup the folders defined for that user as well.  If you don’t you’ll need to cleanup those directories manually. 

Tags:

« Older entries