How to Submit and Execute with Different Account?

[ahkiat]

Hi all, can anyone advise what languages and concept can I use to implement the below idea in Linux? Both application and website is acceptable.

1. User submits file with individual account
2. File will be copied to a central account and a script will be executed in that account.
3. Report of the run script will be accessible to the user.

I tried to Google but could not get any findings.

Thank you.

 

[davidktw]

Hi all, can anyone advise what languages and concept can I use to implement the below idea in Linux? Both application and website is acceptable.

1. User submits file with individual account
2. File will be copied to a central account and a script will be executed in that account.
3. Report of the run script will be accessible to the user.

I tried to Google but could not get any findings.

Thank you.

User account is a virtual segregation in websites or even applications. It does not has to relate to any tangible system account may it be Linux, Windows or any OS real users.

There are 2 accounts here we need to be mindful, one is the process user which when running applications such as a web application, it is normal running under a particular user such as "httpd", "www-data" or could be any system users you specify. There are special cases for unix environments that is capable of assigning different process of the same application using different linux userid, commonly related to chroot, jailing, suexec, etc. Another user concept can be stored in any form of database such as a ldap, flat file, rdbms or as such. This form of users are authenticated normally by web login or other possible authentication mechanism and then the web applications will have routines written to segregate functionalities based on user. These are normally known as Authentication, Authorisation, and Access controls.

For your use case, it quite simple. All it requires is a simple web application running in the Apache web server

The web application will require the user to enter its credential to login. Once login, there will be a upload file for the user to upload your file. If the processing of the file is quick, it can be done in process with the report file stored in the server. Either the report can be display upon response, or a link can be provided for the end-user to download.

If the processing is slow. Then first save the file into a folder, there will be a monitoring script that is monitoring the input file and perform processing on it, where the report can be stored in the server. In this mode, after the user first upload the input file, the response will be just a processing message for the user to wait. The webpage can either periodically refresh or performing a background ajax call to another script to determine if the job is done. Once it's done, the user will be redirected to a page where the report is displayed or a link is available for download.

Now what should the monitoring script be monitoring. One way is monitor a specific directory for input file and then process it. Such method works but have slightly less control because the script need to know which user deposited this file. One can encode this piece of information into the filename to determine, but then after processing, how can the system knows that the job is done ? This has to be thought out. Another way is for script that receive the input file in the first place to write the file into the server and also write a task/job entry into the database. The monitoring script monitors the database for new jobs, pick up the job, process it and then update the entry for completion along with information like where the report is and so forth.

The page or background probe where it is monitoring the database for completed job meant for this particular user will pick up the completion and then proceed to display the report or a link for the user to download.

This form of processing techniques is very commonly designed and does not involved any central account or weird design. Just for your information, for even more scalable design that can deal with large number of processing, message queues can also be used but normally unless you are designing a system dealing with global scale users, normally a single database can handle the load just fine. There are also other databases options such as NoSQL good for such use cases.

Hope I answer your enquiries.

 

[ahkiat]

Hi davidktw, really appreciate for such a detailed explanation.

By the way, I am already working in a internal environment whereby the Linux accounts have been setup and the access is in a LAN environment, i.e no external access allowed (such as Internet access or outside of the office network). So I guess the credential part would be further simplified.

What languages should be used to write the monitoring script? PERL, C++, Python? Is this similar to a loop?

How can I make the script run in a account that I wanted to?

Thank you.

 

[davidktw]

Hi davidktw, really appreciate for such a detailed explanation.

By the way, I am already working in a internal environment whereby the Linux accounts have been setup and the access is in a LAN environment, i.e no external access allowed (such as Internet access or outside of the office network). So I guess the credential part would be further simplified.

What languages should be used to write the monitoring script? PERL, C++, Python? Is this similar to a loop?

How can I make the script run in a account that I wanted to?

Thank you.

I don't think an internal environment makes things easier actually. In fact, the solution that I have proposed for you to consider works internally too. Your users will interact with the system via the browser.

Suppose if you have no HTTP conduit for you to upload the file, how do you expect your users to upload the file ? Most likely FTP or SAMBA ? Would you expect them to SCP into the linux system ? The web approach will be in fact the most straight forward and easier to cope with. If you do not want to setup virtual users, then you might want to resort to PAM integration with the Apache web server. Normally what the user need to authenticate is via HTTP Basic or Digest and when integrated with PAM, will allow using the Linux system users for authentication. I believe this may suffice for your case. Feel free to read up from Apache 2 and HTTP Authentication with PAM | Antarctic Nest of Icephoenix, and google for more information related to PAM and Apache

Any programming languages can be used for your monitoring script. Which programming language normally for me is decided based on familiarity, ease of completing the job, and competency of the developers. There are different approaches to how your script wants to be notified for changes. One traditional approach is by making your monitoring script startup periodically via the unix scheduler, cron. Your script will pick up any files in a directory and process it and then dump the output elsewhere. Another way to use inotify tools to run the script when there is changes to the watched directory. Read up more from http://techarena51.com/index.php/inotify-tools-example/. You could also have your own daemon running that keep polling the directory or database depending on how your job events are going to be scheduled.

Your last question that it must be deposited into individual user accounts has questions to be resolved. How do you notify your end-users that the job has been done ? via email ? or they should go poll themselves periodically ? Using the HTTP conduit, this problem would have been resolved at the application layer.

Typically if you want to write to multiple different accounts in a unix environment, you either run this program as the superuser(root) or same group as the rest of the accounts. For example, create a special group called "mygroup", then place all the end-users into the same group or supplement group "mygroup". Expose a directory inside each of their individual home directory such as "$HOME/output" with "Read-Write" maybe even "eXecute" permission and allow the process to be able to write into these directories. The files will be written with the userid of the running process. If you want to write the files into the respective user ids, you will need to run the program as superuser(root) and change the owner of the files when or after writing.

There is also other approaches more complicated such as how Apache does it, change the effective userid own load into their respective userid, but such designs are more complicated and for your use case, I don't encourage you such design since it is more complicated to maintain.

I think you have to consider from your end-user perspective, are they savvy enough to access the actual Linux account, or a web-based interface works better for them. Also how are your end-users going to read-write the inputs and outputs for your job.

 

[ahkiat]

I was reading up on Apache and CGI these few days.

If I want all the runs to be executed in a specified account regardless of who is the requester and only upon submission of the form i.e no monitoring script, can I use 'suexec'?

suexec mentions that the script can be executed as the user. Which user ia this? The user that invokes the browser?

 

[davidktw]

I was reading up on Apache and CGI these few days.

If I want all the runs to be executed in a specified account regardless of who is the requester and only upon submission of the form i.e no monitoring script, can I use 'suexec'?

suexec mentions that the script can be executed as the user. Which user ia this? The user that invokes the browser?

The user is the linux user of the CGI script. This is not something I will recommend you unless you have no options.

You will want to read up more from suEXEC Support - Apache HTTP Server Version 2.2

You know at the end of the day, I have little understanding why you insist want to run for a particular linux user ? In fact, even if you are using SUEXEC, you still need one separate script for each user.

SUEXEC is normally meant for web hosting where each client get to run their CGI scripts in their respective userid, not the way you wanted it for. This means each user will need their own scripts for SUEXEC to work for them.

For most common apache HTTPd setup, there is a dedicated user for it, normally either HTTPD or WWW-DATA. You can obviously make it run under most linux user except the root(superuser), wouldn't that satisfy your requirement of a specific user ? But I don't see the need for such a move to run as a specific user instead of the default one unless you want all read/write to be under that specific linux user permission.

 

[ahkiat]

It seems that suexec is not the solution here. Actually the reason is more of our work procedure. These runs are supposed to be golden runs which will be kept in the special account.

Any method for that? Can't seem to find any solution in Google.

 

[davidktw]

It seems that suexec is not the solution here. Actually the reason is more of our work procedure. These runs are supposed to be golden runs which will be kept in the special account.

Any method for that? Can't seem to find any solution in Google.

Okay sounds like CI to me. Base on your very initial post in this thread, would your execution of the payload and then generation of the report, the process itself, be run by the destination user ? If not, then let it be run by one specific system user and then have the report generated and email to the destination user.

Like I have given the solution earlier, have your ENDUSER upload the payload in whichever manner you wish, submit it in the form where the script can be run to know who is the owner of the payload, then generate the report and email it back to them.

If you insist want to have the report given to the ENDUSER within the system, then just copy it to the ENDUSER home directory and chown the file to the specific ENDUSER.

The script can be run under root(superuser), if not, at some point run a sudo command on a script that copy the file to the ENDUSER home directory.