Why cannot I change the ownership of my file ?...

For more info visit
A lot of time it would have come to our mind. Why am I not allowed to change the owner of my file in Unix/Linux? Why do I have to be a ROOT user or sudo as a ROOT user when I want to change the ownership of my file? I mean, it's my file. I should have been given the full right to change the owner of my file. Is it necessary for the ROOT to meddle in between !.... I am not trespassing someone else's property. It's not fair enough and blah blah blah...... The answer to all these questions is very simple. Whenever I am changing the owner of my file, it's not something in which only my account is involved. Infact if I had the permission,  it would be like forcing other user to become the owner of my file. So it's kind of dealing with others account also? Now, you may very well ask that why the other user might have problem with this? At the first place, most of the people don't allow anyone to even read their files and look at me, I am giving the ownership of my file to other user. Isn't it fair amount of GENEROSITY. Well, the answer to this question depends on your intentions. Now I will explain it with the help of a simple example that what catastrophe it would have been if you had the permissions to change the owner of your file. Basically everyone knows that they are not allowed to see the contents of /etc/shadow file, which contains password in encrypted format. Though the password for every user is stored in encrypted format, even then you are not allowed to see it. I mean, the ROOT is just taking caution, supposing that some of you could be good hackers. Now I will write a very simple script.   cat>myfile cat /etc/shadow Give all the permissions to everyone for this file.   chmod a+rwx myfile Now we can see, all the users have all the permissions on the file. If you change the ownership of the file from here, supposing that your intentions are to read the contents of shadow file, then let me remind you it would not be very helpful. Even though you can run the file after changing ownership, you will not be allowed to cat /etc/shadow because the script is running with effective UID as your id, who doesn't have the permission to read/write/execute shadow file.  Now you can be smart here, before transferring the ownership to ROOT set SUID for your file.   chmod u+s myfile Then transfer the ownership of your file to ROOT   chown root myfile   Now when the ownership has been transferred and you try to run the file, it would be run with ROOT id as effective UID. So, you would very well be able to see the contents of /etc/shadow file. And then depending on how much you understand encryption/decryption, you could have played a havoc with the system. This is one of the example which justifies that no user should be able to transfer the ownership of their file without ROOT's permission, supposing, in most of the cases ROOT users are trustworthy.

Global Temporary Tables in Oracle

For more info visit
Global Temporary tables are used for temporary storage of data which has to be cleaned up at the end of some task. Generally, batch programs use temporary tables to store data at some temporary location and then the data is automatically deleted/cleaned at the end of the session or at commit. Data in temporary tables is stored in temp segments in tablespace. Data in the temporary table is session specific, i.e a user saved data in a session cannot be accessed by him/her in other session. A user session is associated with the Global Temporary tables when the data is inserted in a session. Now let's see how the Global Temporary table is created Create Global Temporary table my_tab( name varchar(20), Contact number(10) )On Commit [Delete Rows|Preserve Rows];

We can use two options with Global Temporary tables

a) On Commit Delete Rows: If this option is used, data corresponding to the user session is deleted when transaction completes/is committed. b) On Commit Preserve Rows: When this option is used, data in the Global temporary table persists unless the session is over.

Some features of Global Temporary tables

Note: From here whenever I say table just consider it to be Global Temporary table, as it's very tedious to write it again and again. i) Data in a session cannot be accessed in other session. Though different session of a user are using the same Global Temporary table, data of a session cannot be accessed in other session. In short, Data in the table is session specific. ii) If the table is already created by a session and if we try to create table again in other session, it will give an error. iii) At the end of the session or transaction only session specific data is deleted and not the structure of the table from the user's schema. iv) We can run DDL statements(ALTER TABLE, CREATE INDEX) on the table only when it is not used by any other session. v) Truncating table will only delete the session specific data. vi) The scope of the index created on the table is limited to the session which creates it. vii) Views can be created on the table, or on the table and some other permanent table. viii) We can also associate the table with some trigger but remember we cannot reference the table in the trigger. ix) We can have primary key in the table but we cannot create any referential integrity constraint in the table. At the same time, we cannot access the table  in a referential integrity constraint.  x) Abnormal closing  of the session will truncate the session specific data from the table even if the data was not commited or the session was not over.

Anchored Declarations in PL/SQL.

We often declare variables in our PL/SQL programs, and most of the time these variables are used to fetch some values from database tables or store some values in the database tables. The variables used for this purpose should have size and structure  resembling that of table columns. Now, unless you have a very sharp memory, remembering the structure and size of database colums is really a hard task. We can solve this problem by making use of Anchored Declarations. PL/SQL offfer two types of anchoring. i) Scalar Anchoring: In this type of anchoring we use %TYPE attribute to define variable based on some table column or any other PL/SQL variable. ii) Record Anchoring: We can use %ROWTYPE attribute to define a variable based on a row in the table or on an explicit cursor. Let's see the use of Anchored Declarations with the help of an example. Suppose we have a table which has script as shown below. create table contacts(name varchar2(20), mobile number(10)); insert into contacts values('John', 4563821293); insert into contacts values('Paul', 7463292330); In the above script a table contacts has been created and some data is inserted. Now we will write an anonymous block to understand the use of Anchored declarations. set serveroutput on; Declare v_mobile contacts.mobile%type; Begin select mobile into v_mobile from contacts where name='John'; dbms_output.put_line('Mobile no. is '||v_mobile); end; In the above block we are trying to fetch the mobile no. of John. Just see how v_mobile variable is defined with the use of anchored declaration. Just by writing contacts.mobile%type, its datatype is referenced to that of column mobile in the table. This was an example of scalar declaration. In the next example we will see the use of record anchor declarations. We shall again write an anonymous block to demonstrate the use of Record anchored declaration. Declare v_rec contacts%rowtype; Begin select * into v_rec from contacts where name='John'; dbms_output.put_line('Mobile no. is '||v_rec.mobile); end; In the above block we are trying to fetch the whole row in a variable using anchored declarations. Just see, this time we have used %rowtype for fetching the row of a table. To access the individual field we use "variable.columnname", so here we are using v_rec.mobile which is the column name of the table. Not only this, we can also anchor declare a variable based on another PL/SQL variable. A simple PL/SQL block is given below to demonstrate the usage. Declare v_rec contacts%rowtype; v_rec1 v_rec%type; Begin select * into v_rec from contacts where name='John'; v_rec1:=v_rec; dbms_output.put_line('Mobile no. is '||v_rec1.mobile); end; In the above block we are using a variable v_rec1 which is anchored declared based on v_rec.

Advantages of using anchored declarations

Synchronization with Database table columns: Whenever we declare an anchored variable based on row or a column of a table, then the datatype and size of the variable is automatically defined to that of the table column. So, we need not worry about datatype of a variable after anchored declaration. Normalization: Suppose we have declared a number variable as v_num number(5). Now we have the need to declare the same type of variable in a lot of procedures, functions and packages. Now let's say, one day the need arises to change the datatype of this variable from number(5) to number(8). In this scenario it would be a tedious task to search for this variable in all the functions and procedure, and change its datatype. To solve this problem we can make use of anchor declaration based on a PL/SQL variable as follows. create or replace package mypack is v_num number(5); end; declare v_num1 mypack.v_num%type; begin null; end; In the above code we have defined a variable v_num in the package mypack, and later in our procedures and functions we can anchor declare any variable based on this package variable. This solves the problem discussed above. Note: i) Whenever we change the structure of any column in our tables, it is our duty to recompile the functions and procedures, otherwise the functions and packages, using anchor declaration based on table columns, will not work. ii) Keep in mind, in the case of anchored declarations based on a PL/SQL variable, NOT NULL constraint is automatically transferred to the anchor declared variable. In case of anchored declaration based on table columns, this does not happen.

Programmer Defined Subtypes in Oracle.

A programmer can define his/her own subtypes instead of using default subtypes in oracle. Infact these subtypes are defined with the help of default data types only.

User defined subtypes are really easy to use. Suppose we have to declare a varchar of size 3000.
We can declare a varchar of size 3000 as follows.

v_var varchar2(3000);

Now suppose we have to use a varchar of size 3000 in a lot of procedures. Writing this big line again and again in many procedures shall be a pain for us. Also if there is a data flow between different procedures then it is expected that size of the data types in all the procedures should be same. By mistake, a programmer may define different sizes of data types  in different procedures.

In order to solve these problems, we make use of Subtypes.

We can declare the structure of all the variable types,which will be used in our procedures and functions, in a package. Don't worry if you don't know packages. It's just a simple example using package. For the time being , you just take package in oracle as a container.
create or replace package mydatatypes as
subtype mychar is varchar2(20);
subtype mynumber is number(20);
end;


Now we can use mychar,mynumber user defined subtypes in our procedures and functions.These will act in the same way as using varchar2(20),number(20) respectively.

To use these user defined subtype we will write an anonymous block as follows.

 

DECLARE
v_var mydatatypes.mychar;
BEGIN
v_var:='John Smith';
dbms_output.put_line(v_var);
end;

And the output is John Smith.

If you see the block, mydatatypes.mychar is used as a user defined subtype. This is because the mychar subtype is defined inside the package mydatatypes,  and to access it we would have to use mydatatypes.mychar.

We could also have defined subtypes in declaration section of our anonymous block. But that would have defeated the purpose of using subtypes, which are generally used to maintain consistency among data types in different procedures or functions.

For more information visit

Soft links(Symbolic links) in Unix.

Soft Links:-

We have seen hard links in our previous post. Hard links are nothing but more than one names for a file. Hard links have some shortcomings.

i) We cannot hard link two files in different file systems, i.e. a file in /usr directory cannot be hardlinked in /home directory.

ii) Hard links cannot link directories even in the same file systems. It can link only files.

Soft links remove limitations of Hard links.

Now let's see what are Soft links.

We make a file "file1" as shown below

[code]cat>file1
date
[/code]Assign execute permission to this file
[code]chmod u+x file1 [/code]
Now we create a symbolic link "file2" to this file as shown below
[code]ln -s file1 file2[/code]
Note: We are using -s attribute to create a symbolic link. If -s is not used then it would create a hard link.

Now, our symbolic link is created. You can verify the creation of symbolic link using

[code]ls -l file2[/code]
Output is:

lrwxr--r-- 1 user1 user1 2012-04-15 16:14 file2 -> file1

Note: l in the starting and "file2 -> file1" denote the creation of symbolic link. Also, number in the second column is 1. This means, a new file is created, as contrary to Hard links in which no new file is created.

Now we have two files. We know the content of file1 but What does file2 contains?

file2 contains the pathname of file1. When we execute cat command on file2, it actually redirects to file1 and opens its content.
So, cat file1 and cat file2, both show the same content. We can also execute the content using any of the file.

The output of ./file1 and ./file2 are same, i.e.

Sun Apr 15 16:18:28 EDT 2012

 One  advantage of soft link over hard link is that it can link directories also. Suppose we have to link a large number of files from one directory to another. If we use Hard link, then the only way is to link each file individually. But, when we use soft link, we can link an entire directory to another directory.

Caution: Hard link provides safety against accidental deletions, i.e. if one alias is deleted then we can access the file through other aliases.

But, in the case of symbolic link, we created above,  if file2 is deleted then there is nothing to worry about. But, if  by mistake file1 is deleted then all our content is lost.  Also symbolic link file2 would become a dangling symbolic link.This is because symbolic link is a seperate file, and  not a pointer to the original file.

 

For more information visit

What is Hard link in Unix?

Hard Links

By using Hard link we can create an alias for an existing file. Now this file can be accessed by any of the two names, i.e. either by alias or by its original name. Suppose, I create a file "Hello"  as following

 
[code]cat>Hello
echo Hello World
[/code]
Now assign executable permission to this file
[code]chmod u+x Hello[/code]
Now run the file using

[code]./Hello[/code]
And the output will be

Hello World

Now check the details of this file using

[code]ls -l Hello[/code]

-rwxr- -r- - 1 user1 user1 0 2012-04-12 17:58 Hello

Just examine the number 1 after file permission column. This number tells the number of links a file has. At this point its value is 1 wich means that the file can be accessed by only one name i.e. "Hello".

Now, when we create the Hard link for a file, we actually create an alias for a file. When we create a Hard link for a file then it can be accessed by more than one name, but actually it is present at only one space in Hard disk. This means with the help of Hard link more  than one name can point to the actual file. We  make changes to the file using any name, and those changes are reflected in the actual file. Next time when we access the file using some other name, our changes can be seen in the file

Now we will see it with the help of example

To create a Hard link for file Hello write following command on shell.

[code]ln Hello Hi[/code]
Now run the following command

[code]ls -l Hello[/code]
And the output will be

-rwxr- -r- - 2 user1 user1 0 2012-04-12 17:58 Hello

Note: Link number has changed to 2.

This was because alias "Hi" also links to the same file.

In order to confirm that both are same files, type the following command

 
[code]ls -li Hello Hi[/code]
The output will be

4882474 -rwxr- -r- - 2 user1 user1 0 2012-04-12 17:58 Hello

4882474 -rwxr- -r- - 2 user1 user1 0 2012-04-12 17:58 Hi

Note: inode numbers for both the outputs are same. This means there is only one file physically, or in directory system.

Now we can access this file using any of the aliases.

ls -l Hello or ls -l Hi both are same

Now when we execute remove command on Hello

 
[code]rm Hello [/code]
After that execute ls -l Hi. Output will be

4882474 -rwxr- -r- - 1 user1 user1 0 2012-04-12 17:58 Hi

Note: File is not deleted physically, only the alias Hello, which was earlier pointing to the file, was removed. Our data is still conserved in the file and can be accessed using alias "Hi".

Why do we use Hard links? What are the advantages of using Hard links?

i) Hard links provide protection against accidental deletions. Actually this has been shown above, even after we deleted alias "Hello", we could access the file using alias "Hi".

ii) Suppose we have some programs which expect a file in their directory. Now, we moved that file from that directory to some other directory. So, instead of changing path of the file in individual programs we can just make a hard link of that file in programs' directory.


For more information visit

What is Sticky bit?

Sticky bit is used for advance level file permission in Unix. It is one of the twelve bits used in File security.  Generally, users know only about nine bits which are used in File permissions, i.e. 3 for user/owner, 3 for Group to which the file owner belongs and 3 for others. There are 3 other bits also used for advance level file permissions

i) SUID bit

ii) SGID bit

iii) Sticky bit

I already explained the use of SUID bit in this post.

Sticky bit can be used with files, as well as directories. Sticky bit is rarely used with files these days. The main use of Sticky bit comes when it is used with directories.

Sticky bit with files

Sticky bit is used with files in order to make it persist in the swap area or memory. In earlier days when RAM was limited in size, the scheduler used to swap programs very swiftly from RAM to Hard drive. This would cause problems when the part of the program was used very frequently in some process. So, what the programmer would do. He used to set sticky bit on files which were used very frequently, in order to retain them in the memory.

Now a days we have RAM of very high capacities, so Sticky bit is rarely used on files.

Sticky bit with directories

The main use of sticky bit is with directories. For understanding this, we will have to understand  file permissions on directories.

Suppose there is a public directory,  "pubdir" , which has permissions like following

rwxrwxrwx

Since it is  a public directory, it has executable and write permissions for everyone. Now suppose, I have a file "myfile" which is in this public directory , and I have given it permission like following

rwxr- -r- -

I have not given write or execute permission to others. This means that any other user will not be able to edit or execute my file. But will heshe able to delete my file? Well that depends on the directory permissions in which my file is residing.

Now, let's understand "pubdir" directory permissions.

i) Everyone has read permission: Everyone will be able to see the contents of this directory using   ls -l.

ii) Everyone has execute permission: Everyone will be able to access the directory, access on a directory means, anyone can go inside directory using cd command.

iii) Everyone has write permission: Anyone will be able to edit/delete any of the contents of directory.

Now, what are the contents of a directory?...........wwwoooooo  FFFFFFFFiiiiiiiilllllllllleeeeeeeeeeessssssssss.

Damn it. All the files, owned by any user, are vulnerable to a lot of threats.

Now you understood the problem.

Don't worry, we have a solution in the form of Sticky bit. When we set sticky bit for a directory then it puts a restriction on the directory that only the file owner of the file, which is inside the directory, will be able to delete it, and not anyone else.

Sticky bit can be set in the following way.

chmod +t filename

After setting the sticky bit, the directory permission would look like

rwxrwxrwt

The most practical use of sticky bit is in /var/temp. temp directory is public and common to every user.

For more information visit

Why is SUID bit used?

Whenever a file, in which SUID bit is set by owner, is run by some user, the process runs with the identity and permission of owner and not of the user running the file.

Suppose we have a file "file1" whose permissions are shown as below.

-rwxr-xr-x

Let this file be owned by John. Now let there be another file "file2", owned by John, which has permissions as follows.

-rwxr- -r- -

 "file2" can only be modified by John, who is the owner of the file. Suppose, this file stores the information about the employees working under John. Lee is one of the employee working under John, i.e. Lee's data is also stored in "file2". Now if John had given write permission to others and groups, then anyone would have been able to change anyone's data using vi editor.

John didn't want that, but also he wanted to make things simpler. So, what he did? He didn't give write permission to any of the employees for "file2", instead, he made another file "file1" on which he gave execute permission to everyone. He also set the SUID bit for "file1" because of which,when some user tries to execute "file1", the process will be executed with John's identity and permission.

Now when the process is executing with John's identity, it can very well change the contents in "file2", since John has write permission on "file2". In other words, John has cutomized the changes which an employee can make to "file2".  Now a user cannot just open a file in vi editor and make any changes he/she wants. Instead, he will only be allowed to make changes in "file2" as determined by the program written in "file1".

So, that is the advantage of using SUID bit.

We set the SUID  bit for "file1" as

chmod +s file1

After the SUID bit is set, the file permissions for "file2" will be as follows

-rwsr-xr-x

Did you notice the 'x' bit in user set changed to 's' ?. This confirms that SUID bit has been set for "file1".

In this way "file2" could not be modified by any employee using vi editor but can be modified by script/program in "file1" using owner's permission. Wasn't that amazing?

 


For more information visit

How to write and execute a named PL/SQL block?

Writing and executing a named PL/SQL block is as simple as writing an anonymous PL/SQL block.

There are many ways to write a named PL/SQL block. I will be dealing with each and every way in subsequent posts.  This post deals with writing of  a stored Procedure. Stored procedures and functions are stored inside Oracle, and can be called at any place in the same way as we call any function in any programming language.

The main advantage of stored procedure is that, you don't have to write your logic again and again. You can write your logic once, and use it whenever you want, on the simple call of a procedure/function.

Now we will write the code for a simple stored procedure

 

 
[code]CREATE OR REPLACE PROCEDURE sampleproc(p_arg number)
AS
v_var number(4);
BEGIN
v_var:=p_arg;
IF(v_var>1000) then
DBMS_OUTPUT.PUT_LINE('Input greater than 1000');
else
DBMS_OUTPUT.PUT_LINE('Input less than 1000');
END IF;
END sampleproc;
/
[/code]

Now we can execute this procedure in a number of ways.

a) Execute it from some other block

The stored procedure created above can be executed from any other block, it may be anonymous block, procedure or function.

 
[code]
BEGIN
sampleproc(1001);
END;
/
[/code]

b) Execute it directly from SQLPlus.

EXECUTE sampleproc(1001);

Note: SET SERVEROUTPUT ON for output.


For more information visit