Differences

This shows you the differences between two versions of the page.

--- haas:spring2017:sysprog:projects:sci0 [2017/01/26 16:40] – [Program] wedge
+++ haas:spring2017:sysprog:projects:sci0 [2017/02/14 17:00] (current) – [Submission] wedge
@@ Line 31: / Line 31: @@
 </code>
+====Setting permissions====
+Although we've largely operated without direct attention to it, our data and our access to it very much depends upon the permissions set on them.
+You cannot view any source code written without the read permission being set; you cannot save changes unless you have write permission enabled; and you cannot run your compiled programs if the execution permission was not applied.
+Different operating systems and different filesystems manifest file permissions differently; for this problem we will specifically explore the UNIX file permissions, by writing a program that accepts a value and a file from the command-line and does the pre-processing necessary to convert that value into a form compatible with the mechanism for actually changing the permission.
+UNIX file permissions are represented as a 3-digit octal (base 8!) value, and each octal value can have the following values:
+^  value  ^  description  |
+|  4  |  apply read permission to that particular mode  |
+|  2  |  apply write permission to that particular mode  |
+|  1  |  apply execute permission to that particular mode  |
+|  0  |  apply no permissions to that particular mode  |
+Being an octal value, we can express results ranging from 0-7, and that is precisely how many variations we need to specify all the possible combinations here.
+For example, if we wanted read (4) and write (2) permission, we'd add them together... 4+2 is 6; if we wanted read, write, AND execute: 4+2+1 = 7.
+There are 3 'tiers' of permissions to consider:
+^  tier  ^  description  |
+|  user  |  permissions applied to the assigned owner of the file  |
+|  group  |  permissions applied to the assigned group of the file  |
+|  other  |  permissions applied to anyone else (the world)  |
+More specifically:
+^  ^  user  ^  group  ^  other  |
+|  read  |  0400  |  0040  |  0004  |
+|  write  |  0200  |  0020  |  0002  |
+|  execute  |  0100  |  0010  |  0001  |
+|  none  |  0000  |  0000  |  0000  |
+To form the octal permission, we figure out what permissions to apply to the user (a combination of read, write, execute, or none), and then for the group, and finally for the world. That is the 3-digit octal value we need.
+The problem is that the mode as specified on the command-line will be available as a string (argv[1], an array of characters), so your main task will be to convert that character data into base 8 data (or binary, or hex, the same thing in the end).
+Your program should expect data to be provided as follows:
+  * argv[0]: program name
+  * argv[1]: 3-digit permission (as a string)
+  * argv[2-n]: file to which we want to apply permissions
+This can be done rather effectively using logic operations (almost crazy easily).
+To get a better handle on this, you may run the following commands when logged into lab46:
+<cli>
+lab46:~$ ls -l /etc/motd /etc/shadow /bin/ls
+-rwxr-xr-x 1 root root   118280 Mar 14 11:47 /bin/ls
+-rw-r--r-- 1 root root   859 Mar 14 12:16 /etc/motd
+-rw-r----- 1 root shadow 729 Oct 21 04:55 /etc/shadow
+lab46:~$
+</cli>
+Ignoring the leading '-' (that refers to file type), we see that **/bin/ls** has **rwx** (7) applied to the user root, **r-x** (5) applied to the group root, and **r-x** applied to everyone else. That means its octal permission is 0755.
+**/etc/motd** has permissions of **0644**, while **/etc/shadow** has permissions of **0640**.
 =====Program=====
@@ Line 41: / Line 99: @@
     * the file(s)
   * perform the task (process)
-    * isolate one's digit mathematically, store in a variable (unsigned short int)
+    * as stated, you are not allowed to use any of the **strtol(3)** family of functions to do the base conversion for you.
-    * isolate remaining digits mathematically, store in another variable (unsigned short int)
+      * This isn't to say you cannot use them; you may, you just cannot use them to do any of the conversion work (beyond ASCII to base 10).
-    * perform the algorithm on the two pieces, storing their results in two separate variables (of type unsigned short int)
+  * display error or usage if applicable.
-  * display the final value (output)
+    * if error or usage, make sure you return a 1 instead of 0.
-    * display the beginning and ending parts together (but stored in separate variables)
-    * display the resulting number to STDOUT (right-justified in a space supporting the largest possible value -- see output example below)
-    * display any supporting text to STDERR (display of source values left-justified in a space supporting 3-digit values -- see output example below).
-  * because we have not officially learned how to do selection/have the computer react to conditions, please implement with the assumption that the user will ALWAYS input a correct value. Do not worry about having to check for invalid or illegal input values (I will not be checking for such when I evaluate your project).
 =====FAQs/Hints=====
@@ Line 157: / Line 211: @@
 =====Execution=====
-<cli>
+If you run without proper arguments:
-lab46:~/src/cprog/sof0$ ./sof0
-Enter value: 75
-  x 75  =   5625
-lab46:~/src/cprog/sof0$
-</cli>
-The execution of the program is short and simple- obtain the input, do the processing, produce the output, and then terminate.
-Note how the two "75" values are left-justified within a 3-space slot (with the multiplication 'x' and equal sign '=' being padded with a space on either side). This information should all be displayed to STDERR.
-Similarly, here's an example of 105x105:
 <cli>
-lab46:~/src/cprog/sof0$ ./sof0
+lab46:~/src/sysprog/sci0$ ./mychmod
-Enter value: 105
+./mychmod <MODE> <FILE> [FILE...]
-x 105 =  11025
+lab46:~/src/sysprog/sci0$
-lab46:~/src/cprog/sof0$
 </cli>
-The 'x' and '=' padding persists, but because we're squaring a 3-digit value vs. a 2-digit value, we occupy the entire allocated space on the screen.
+Run with invalid mode:
-If you'd like to verify successful output to STDOUT/STDERR, you can perform the following tests. First, verify that the answer (and ONLY the answer), is being sent to STDOUT -- we do this by eliminating STDERR entirely:
 <cli>
-lab46:~/src/cprog/sof0$ ./sof0 2> /dev/null <<< 105
+lab46:~/src/sysprog/sci0$ ./mychmod 0987 file1
+ERROR: invalid mode
-lab46:~/src/cprog/sof0$
 </cli>
-What we are doing here is two-fold:
+Run with valid mode (success means you just get your prompt back):
-  * We are using command-line I/O redirection to redirect STDERR (which is bound to file descriptor #2) to the system bit-bucket.
-  * We are "redirecting" STDIN using a **here string**, providing the program's input of **105** right on the command-line at time of execution.
-Similarly, if we were to eliminate STDOUT entirely (for verifying STDERR output):
 <cli>
-lab46:~/src/cprog/sof0$ ./sof0 1> /dev/null
+lab46:~/src/sysprog/sci0$ ./mychmod 640 file1
-Enter value: 75
+lab46:~/src/sysprog/sci0$
-  x 75  = lab46:~/src/cprog/sof0$
 </cli>
-What we are doing here:
-  * We are using command-line I/O redirection to redirect STDOUT (which is bound to file descriptor #1) to the system bit-bucket.
-=====Verification=====
-One of the tests I will perform for output compliance of your code will involve comparing your program's output against a range of input values, to see if they all output in conformance with project specifications.
-I will make use of a checksum to verify exactness.
-You will need to run this from your sof0 project directory with a compiled and operational binary by the name of **sof0**.
-You can check your project by typing in the following at the prompt:
-<cli>
-lab46:~/src/cprog/sof0$ pchk cprog sof0
-</cli>
-If all aligns, you will see this:
-<cli>
-==================================================
-=   CPROG sof0 project output validation tool    =
-==================================================
-sof0 checksum is: 822a47fb2a45845500b6c10878045bd5
-your checksum is: 822a47fb2a45845500b6c10878045bd5
-==================================================
-    verification: SUCCESS!
-==================================================
-</cli>
-If something is off, your checksum will not match the sof0 checksum, and verification will instead say "**MISMATCH**", like follows (note that a mismatched checksum can be anything, and likely not what is seen in this example):
-<cli>
-==================================================
-=   CPROG sof0 project output validation tool    =
-==================================================
-sof0 checksum is: 822a47fb2a45845500b6c10878045bd5
-your checksum is: 92af264c86823a61529948caaeac53e0
-==================================================
-    verification: MISMATCH
-==================================================
-</cli>
-=====Questions / Food for Thought=====
-These are things I'd like you to contemplate, even use as potential material on your weekly journal entry. The more you think about and understand the problem, the better your ability to solve it and other problems.
-  * Why/how does this trick work for 1-digit numbers?
-  * Considering our 1-, 2-, and 3-digit domain restriction for this project, how many candidate values are there for input?
-  * What is the smallest input value?
-  * What is the largest input value?
-  * How many input values are there that end in **5**?
-  * What is the largest square that can be calculated given the project input restrictions?
-  * How many digits is the largest square?
-  * How can knowing how many digits the largest square is help you implement your solution?
 =====Submission=====
-To successfully complete this project, the following criteria must be met:
-  * Code must compile cleanly (no warnings or errors)
-  * Executed program must display a total of 2 lines, one for input, one for output.
-    * The computed number must be output to STDOUT
-    * Any supporting output must be output to STDERR
-    * Output is formatted in the manner in the sample above
-  * Output must be correct, and match the form given in the sample output above.
-  * Code must be nicely and consistently indented
-  * Code must implement solution using the mental math technique described above
-  * Code must be commented
-    * have a properly filled-out comment banner at the top
-    * have at least 20% of your program consist of **<nowiki>//</nowiki>**-style descriptive comments
-  * Output Formatting (including spacing) of program must conform to the provided output (see above).
-  * Track/version the source code in a repository
-  * 25% late penalty per day after deadline
-  * Program is submit in a C source file called **sof0.c** and compiles without warning, note, nor error with gcc on lab46.
-  * Submit a copy of your source code to me using the **submit** tool.
 To submit this program to me using the **submit** tool, run the following command at your lab46 prompt:
 <cli>
-$ submit cprog sof0 sof0.c
+$ submit sysprog sci0 mychmod.c
-Submitting cprog project "sof0":
+Submitting sysprog project "sci0":
-    -> sof0.c(OK)
+    -> mychmod.c(OK)
 SUCCESSFULLY SUBMITTED
@@ Line 285: / Line 248: @@
 You should get some sort of confirmation indicating successful submission if all went according to plan. If not, check for typos and or locational mismatches.
-I'll be looking for the following:
-<code>
-:sof0:final tally of results (52/52)
-*:sof0:adequate indentation and comments in sof0.c [4/4]
-*:sof0:data stored and calculated in correct and separate variables [4/4]
-*:sof0:effective usage of fprintf() and fscanf() [4/4]
-*:sof0:program uses indicated algorithm [12/12]
-*:sof0:output conforms to project specifications [12/12]
-*:sof0:runtime tests of sof0.c succeed [12/12]
-*:sof0:no negative compiler messages for sof0.c [4/4]
-</code>

Lab46 Wiki

User Tools

Site Tools

Differences

Page Tools