File Permissions Nightmare!

Platform: Solaris 5.7
I'm trying to develop a script in Perl (but this is not a perl question).  That I would make world-readable and executable from my account for students to submit their solutions to programming assignments.  For example, the student would write the code (happens to be java), compile, see that it works and then turn it in by running
prompt> ~myusername/submit.pl studentscode.java
The script copies over the file just fine (to a subdirectory of my home with the students' user name) but now I need for the script to make the file unreadable and unwriteable by anyone but me (and the directories the same way).  A problem I have encountered is that I think the system administrator has disabled chown (I get a "not owner" error even though I am the owner).  Possible solutions are: running the script setuid as me, or having the script email the file to me and then writing procmail rules to process it.  I am familiar with neither of these methods so I could use some help and suggestions.  Thanks in advance.
LVL 4
adam923Asked:
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

joe_hCommented:
The setuid method is, that you set your script world-readable and world-executable and at the same time set the set-uid bit with:

chmod 6755 submit.pl

Then, the script will run with your UID and GID (as if you have run it yourself). Any files that this script creates should be owned by you, allowing you to change the permissions any way you want them. I'm not sure if it will be able to read the submitted file (unless it is world-readable), though - you may want to have it submitted with

cat studentscode.java | ~yourusername/submit.pl

Anyway, I didn't try this out, so you might want do do a little experimenting and let me know if it works or not.
0
adam923Author Commented:
this didn't work... maybe something is configured weird in my system that prevents running setuid because when i did this the "s" characters did show up in ls -l but when i ran the perl script and printed the values of $<and $> (real and effective user id) they're always the user's id and never mine, the file created is still owned by the user of the script.
0
jlevieCommented:
The failure of using the suid bit sounds like your environment uses auto mounted homes directories and those directories are being exported with the "nosuid" option. This is frequently done for security reasons, and disables the suid function.

Emailing the file is the solution. It's very easy to do from within your perl script. Assuming the file name is in $ARGV[0],  a simple version of the code to mail it to yourself would look like:

system( "mail -w myself@best.edu <$ARGV[0]");

This works, but the email won't have a Subject line, nor will it have a From line. A fancier version that includes these headers (and makes procmail filtering easy) would be:

open(INP, "$ARGV[0]") || die "Can't open input $ARGV[0]\n";
open(TMP, ">$ARGV[0].tmp") || die "Can't create tmp file $ARGV[0].tmp\n";
print TMP "From: $ENV{'LOGNAME'}\@best.edu\n";
print TMP "Subject: CS205 Assignment\n";
print TMP "\n";
while(<INP>) { print TMP $_; }
close(TMP);
close(INP);
system("mail -w self@best.edu <test.tmp");
unlink("$ARGV[0].tmp");

0
Cloud Class® Course: MCSA MCSE Windows Server 2012

This course teaches how to install and configure Windows Server 2012 R2.  It is the first step on your path to becoming a Microsoft Certified Solutions Expert (MCSE).

adam923Author Commented:
Please only post comments, I will promote a comment to an answer when the problem is solved.
What's the advantage of making a temp file to send over opening a pipe to the mail program?
Sending is only half the story, (as indicated in the question) how do i process the email from my end?  I'd like to parse the bodies of the messages out into separate files in subdirectories named after the sender.  I believe this is done with .procmailrc but I have never done it before.  If someone could get me started with the settings for this file that would be much appreciated.
0
joe_hCommented:
man procmail
man procmailrc
man procmailex
:-)))

Okay, more hints:
..procmailrc contains "recipes" for delivering incoming mail. Each recipe starts with a :0 (that is , colon zero), followed by optional flags. Following lines starting with * indicate conditions that must be true for this recipe to apply to a particular mail. Then, a line after that specifies what to do with the mail.

:0 c
* ^Subj.*homework
homeworks

This copies (note "c" flag) all mails with "homework" in subject to a mail folder called "backup" - it is good to include such a safety feature in case you mess up the following recipes.

:0
* ^Subj.*homework
| some_script

This should pipe any such messages into the "some_script" program. Here, I'm not sure whether something else (perhaps flags dealing with lockfiles?) needs to be considered - don't take my example here for sacred. Since there's no "c" flag, the mail is considered "delivered" by this recipe and further recipes do not apply to it.

In the script, you would probably do some cd, mkdir, and pipe the mail into uudecode.

My source for this information were the above man pages, I didn't actually try much of this (except the "back-up" recipe which I know that works). So, please let me know if it works for you.
0
joe_hCommented:
oops, the folder name the :0 c ... recipe copies to is "homeworks" (duh..)
0
jlevieCommented:
Okay, the reason for creating the temp file is to get headers into the message. Like most things in perl there are a number of ways this can be done. You can, using only what's in a standard perl installation and using ordinary Solaris utilities, do it with a temp file. Alternatively, if you have the privs, you can add one of the perl email modules to your perl installation and use it to construct the message. I didn't want to offer a solution that required root privs to implement as I can't assume that you have root privs.

As to the procmail rules, I didn't offer any because I don't have access right now to procmail on Solaris to be able to test with (the perl code was tested to be sure it would work). If you want an untested procmail rule, add an "X header to the perl code containing the name of the file (print TMP "X-Header-Name: $ARGV[0]\n") and try something like:

FROM=`formail -xFrom:`
TASK=`formail -xX-Header-Name:`
:0 b
* ^Subject: CS205 Assignment
$FROM/$TASK

Since I can't test this it's not clear what the file perms will be on the student's data. If they aren't as desired, you could provide a shell script or perl script that accepts the destination path/name, reads the data from stdin, writes it to the path/name, and changes the perms when done. This would change the last line of the procmail rule to be:

! savit $FROM/$TASK
0
jlevieCommented:
Okay, the reason for creating the temp file is to get headers into the message. Like most things in perl there are a number of ways this can be done. You can, using only what's in a standard perl installation and using ordinary Solaris utilities, do it with a temp file. Alternatively, if you have the privs, you can add one of the perl email modules to your perl installation and use it to construct the message. I didn't want to offer a solution that required root privs to implement as I can't assume that you have root privs.

As to the procmail rules, I didn't offer any because I don't have access right now to procmail on Solaris to be able to test with (the perl code was tested to be sure it would work). If you want an untested procmail rule, add an "X header to the perl code containing the name of the file (print TMP "X-Header-Name: $ARGV[0]\n") and try something like:

FROM=`formail -xFrom:`
TASK=`formail -xX-Header-Name:`
:0 b
* ^Subject: CS205 Assignment
$FROM/$TASK

Since I can't test this it's not clear what the file perms will be on the student's data. If they aren't as desired, you could provide a shell script or perl script that accepts the destination path/name, reads the data from stdin, writes it to the path/name, and changes the perms when done. This would change the last line of the procmail rule to be:

! savit $FROM/$TASK
0
jlevieCommented:
Sorry, didn't mean to get two copies of the comment in
0
jonkeCommented:
Why are you trying to chown the file if you are already the owner??
0
adam923Author Commented:
i am not the owner, the student is
0
jonkeCommented:
No chown solutions will work as by default chown is restricted to being used by root. Are you super user?

If you can get your sys admin to add

set rstchown = 0

to /etc/system, then you would be able to get permissions as a user on the system to 'give' files to other people.

The only other possibility is to have the sysadmin own the script and have it setuid so it runs as root. Then at the start of the scripts, you can have it chown and chmod it so that only you can read it. Depends on how nice your sys-admin is really.

Otherwise your going to have to try and use that mail solution which looks more trouble than its worth really.
0
ahoffmannCommented:
didn't read the whole bunch of comments, anyway
Solaris' kernel is configured to not allow suid scripts bey default. You need to change this kernel setting to use perl scripts with suid, or a special program like sudo.
0
adam923Author Commented:
i don't have access to any sysadmin or kernel settings, i am not root nor will i ever get the people who are to cooperate
the mail solution is worth the trouble, i've been working on the .procmailrc so any suggestions there are appreciated
please explain what sudo does and if it's a feasable alternative for me, someone with no root access
0
ahoffmannCommented:
sudo is a program with the user's s-bit set and owned by root, so it is possible to run any other program as root. sudo can be configured to be used just by authorized users. Of corse, the admin need to install and configure it.
If you cannot gain root access, you cannot change ownership, usually. This is UNIX's simplest security ;-)
0
adam923Author Commented:
well i guess that is out of the question then... the simplest security is also the stupidest, why wouldn't it let me give files that i own away ??
anyway, i guess .procmailrc it is... any suggestions are welcome
0
expert99121199Commented:
wow - this is simple if you create the output files first for the students with world writable permissions.  Tell them to submit with their email name as an argument, have pre-built files with those names, and let 'er rip.

If you want to prevent overwrites, only write to empty files, or use append and see change history in the files.

KISS
0

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
adam923Author Commented:
i'll try that method... looks interesting but it assumes one student will not write to another's files, right?
0
expert99121199Commented:
If you wish you can set the files up, then chown them to the students.  Under UNIX you can always chown AWAY from you but not TO you
0
adam923Author Commented:
unfortuately i cannot chown away from me... seems to be some "security" feature set up by my wonderful system administrators
from the chown manpage
 The   operating   system   has   a   configuration    option
     {_POSIX_CHOWN_RESTRICTED},  to  restrict  ownership changes.
     When this option is in effect  the  owner  of  the  file  is
     prevented  from changing the owner ID of the file.
0
expert99121199Commented:
OK - you can still implement the "write only to empty files" rule - or give each student a "key" and look for that as the second argument of the submit command.  Not too tough.  Adds a bit to the submit script, but it keeps the security up.


Pre-creating the files with writable permissions is the key.
0
expert99121199Commented:
One more think - sorry, it's late - have the perl script see who is executing it and write to the appropriately named pre-created file.  Unless the rascals share accounts or intentionally 'cd' over to your area just to cause problems this will be secure.

You may want to "hide" the submission directory by naming it with a leading dot just to filter out the non-motivated students.  Of couse, they can read your perl script to figure things out.  If you are really worried, have the completed perl script converted to c and compiled.  That would tighten things up quite a bit.

0
adam923Author Commented:
ok, this sounds great so i'll try it tomorrow if i get time
thanks for your patience
0
ahoffmannCommented:
> Under UNIX you can always chown AWAY from you but   not TO you
NO, not always.
See previous comments about kernel and POSIX.
If this kind of security is on your system, you need root permissions, no way around this, usually.
0
adam923Author Commented:
worked great! i have two perl scripts... one that i run to set up the files and one that any student can run to submit their assignments

any tips on converting perl -> c? i've never done it before
0
expert99121199Commented:
I'm glad it worked for you.  I would copy the files into a private area regularly to prevent a malicious student from nulling everyone's homework.  A third script executable only by you would make that easy.  Tell it to skip empty files.

Sorry I can't help with the c conversion, that would be a topic unto itself (porting perl -> c), and it is beyond me.
0
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Unix OS

From novice to tech pro — start learning today.