Answers to

     

Answers to "File and Directory Permissions" Questions

A1:

Using the /bin/umask command will set the umask for the process that executes the /bin/umask command. Files and directories created within that process will have their file creation mode affected by the umask. When the /bin/umask command finishes, the user will return to using the umask set in their shell.

A2:

Default file creation mode = 0666(rw-rw-rw-). With this umask, the new file with have mode 0640 (rw-r-----).

A3:

Execute and write on the directory NOTHING ELSE!

A4:

No. If you can append to a file, you can modify all content, i.e., remove all content, but not necessarily delete the file. The result is as disastrous if the data was important.

A5:

A hard link is simply a new directory entry that references the same inode as the original directory entry. As such, both directory entries reference the same inode where the file ownerships and mode are stored; hence, they reference the same information.

A6:

The /bin/login and /bin/passwd commands are SUID to root, meaning that while they are running, the process is effectively running as root regardless of the users real UID.

A7:

Possible, but not all answers:

  1. Shell scripts need to be readable in order to act as programs.

  2. If relative pathnames are used in the script, a corrupted PATH variable can reference bogus files that will be executed as root, instead of the valid OS programs.

  3. Potentially, a corrupted IFS variable can alter the meaning of tab and space characters , causing a simple command line to be interpreted as a single command that could be a bogus program created by the user.

  4. If the shell used sets up an SUID shell process first and then reads the shell script in line by line, the user could replace the original shell script with a bogus file of his choosing.

A8:

SUID programs only change your effective UID. Lots of applications will check your real UID as a security measure. A user's real UID is set at login time. The effective UID is set at login time, but can be changed by SUID programs/scripts. The following program will execute the program passed on the command line with the real UID of root:

 

 root@hpeos004[]  cat realUID.c  #include <stdio.h> #include <stdlib.h> #include <unistd.h> main(argc,argv) int argc; char *argv[]; {         int uid;         if (argc != 2)         {                 fprintf(stderr, "Usage: 
 root@hpeos004[]  cat realUID.c  #include <stdio.h> #include <stdlib.h> #include <unistd.h> main(argc,argv) int argc; char *argv[]; { int uid; if (argc != 2) { fprintf(stderr, "Usage: $0 <program>\n", argv[0]); exit(1); } setresuid(0,0,0); execlp(argv[1], argv[1], (char *)0); } root@hpeos004[] 
<program>\n", argv[0]); exit(1); } setresuid(0,0,0); execlp(argv[1], argv[1], (char *)0); } root@hpeos004[]

The only requirement is that this program is run as SUID-to-root, but I could never advocate using such a program on a production system.

A9:

SGID on a directory will mean that all files created in the directory will have group ownership matching the group ownership of the directory itself. This means that a file created by fred:quarry will have group ownership of sys (directory owned by root:sys) in this example.

A10:

The sticky-bit got its name from the notion of sticking the program code in the virtual memory system. Every subsequent invocation of a program would not require the program code being read from the filesystem because it was already in the VM system and just needed to be swapped in. Most systems these days have large memory and don't need to swap out very often. Even if they do need to swap out data, there is a possibility that the code pages will not have been removed and can be reclaimed from the memory free-list by the VM system.

A11:

Set the sticky-bit on the directory; chmod o+t <directory> means that only the owner of the file, the owner of the directory, or root can delete the files in the directory.



HP-UX CSE(c) Official Study Guide and Desk Reference
HP-UX CSE(c) Official Study Guide and Desk Reference
ISBN: N/A
EAN: N/A
Year: 2006
Pages: 434

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net