 |
 |
| What are the PERL/CGI
paths? |
 |
 |
RedHat Linux server
PERL executable path: /usr/bin/perl
cgi-bin path: /home/USERNAME/cgi-bin
Or you can use Webshell to access your account with the same information as your FTP
account. A couple of hints: -upload your cgi file in ascii format -change permissions on
the cgi file either through Webshell or through your FTP software.
A couple of hints: -upload your cgi file in ascii format
-change permissions on the cgi file either through chmod at the unix prompt, or
through your FTP software.
/bin/date
/usr/bin/time
|
|
| What is the Sendmail path? |
|
|
Sendmail path: /usr/sbin/sendmail
|
|
| How to access UNIX
Statistics? |
|
|
|
|
| What type of FREE Shopping
Cart does ArmmNet offer? |
|
|
- PerlShop is no longer supported. We are currently
investagating an
alternative cart.
(There is no Tech Support for this Software)
|
|
| How do I untar files on my
UNIX account? |
|
|
You can now untar files in your UNIX account through your
shell program. You can upload the file to any location on your account. You then go to
that file in the left hand side of the Webshell program (the side that is labeled as
source). To determine where the file will uncompress to, on the right hand side of the
screen (labeled as Destination), go to that specific directory. Now click on the
compressed file in the source directory and Webshell will uncompress the file to the
destination directory.
A few tips:
- Allowable file extensions:
.tgz
.tar
.gz - just a single zip
- Remove underscores from the filename.
|
|
| How do I password protect
my directories and/or files? |
|
|
You can password protect directories and files with a tech
support request to enable the shell access. Use a shell program you will be able to change
the permissions and edit your .htaccess file.
|
|
| How do I edit my .htaccess
file? |
|
|
You can password protect directories and files with the shell
software. In the bottom right hand corner of Webshell, change the mode to
"Protect" and then click on the directory or file you want to protect. A new
screen will appear allowing you to edit your .htaccess file.
|
|
| What are the paths to
utilize the secure server (SSL)? |
|
|
Request secure server
access:
The path to the secure web page MUST be an absolute link of:
https://ssl.securedvault.biz/yourdirectory/filename.html
To access your CGI and PERL scripts securely:
https://ssl.securedvault.biz/yourdirectory/cgi-bin/script.cgi
|
|
| How do I untar (uncompress)
files in shell? |
|
|
After logging into shell, select the directory
which contains the compressed file(s) in the left hand side window labeled as
Source. In the right hand side window labeled as Destination, you need to select the
target directory in which you want the file to uncompress to. Then all you need to
do is click on the filename in the Source window and the file (if compressed and named
properly) will uncompress with all its directory structure to the Destination directory.
These are the file extensions that Webshell will
recognize and uncompress:
Part of the time the problem is with the script itself, so
make sure you check everything. If you know the problem is on our side please use the
timestamp to mark the exact time and date that the problem occurred.
Unix file permissions :
r w x r - x r - x
The suEXEC feature -- introduced in Apache 1.2 -- provides
Apache users the ability to run CGI and SSI programs under user IDs different from the
user ID of the calling web-server. Normally, when a CGI or SSI program executes, it runs
as the same user who is running the web server.
Used properly, this feature can reduce considerably the
security risks involved with allowing users to develop and run private CGI or SSI
programs. However, if suEXEC is improperly configured, it can cause any number of problems
and possibly create new holes in your computer's security. If you aren't familiar with
managing setuid root programs and the security issues they present, we highly recommend
that you not consider using suEXEC.
- Was the wrapper called with the proper number of
arguments?
The wrapper will only execute if it is given the proper
number of arguments. The proper argument format is known to the Apache web server. If the
wrapper is not receiving the proper number of arguments, it is either being hacked, or
there is something wrong with the suEXEC portion of your Apache binary.
- Is the user executing this wrapper a valid user of
this system?
This is to ensure that the user executing the wrapper is
truly a user of the system.
- Is this valid user allowed to run the wrapper?
Is this user the user allowed to run this wrapper? Only one
user (the Apache user) is allowed to execute this program.
- Does the target program have an unsafe hierarchical
reference?
Does the target program contain a leading '/' or have a '..'
backreference? These are not allowed; the target program must reside within the Apache
webspace.
- Is the target user name valid?
Does the target user exist?
- Is the target group name valid?
Does the target group exist?
- Is the target user NOT superuser?
Presently, suEXEC does not allow 'root' to execute CGI/SSI
programs.
- Is the target userid ABOVE the minimum ID
number?
The minimum user ID number is specified during configuration.
This allows you to set the lowest possible userid that will be allowed to execute CGI/SSI
programs. This is useful to block out "system" accounts.
- Is the target group NOT the superuser group?
Presently, suEXEC does not allow the 'root' group to execute
CGI/SSI programs.
- Is the target groupid ABOVE the minimum ID
number?
The minimum group ID number is specified during
configuration. This allows you to set the lowest possible groupid that will be allowed to
execute CGI/SSI programs. This is useful to block out "system" groups.
- Can the wrapper successfully become the target user
and group?
Here is where the program becomes the target user and group
via setuid and setgid calls. The group access list is also initialized with all of the
groups of which the user is a member.
- Does the directory in which the program resides exist?
If it doesn't exist, it can't very well contain files.
- Is the directory within the Apache webspace?
If the request is for a regular portion of the server, is the
requested directory within the server's document root? If the request is for a UserDir, is
the requested directory within the user's document root?
- Is the directory NOT writable by anyone else?
We don't want to open up the directory to others; only the
owner user may be able to alter this directories contents.
- Does the target program exist?
If it doesn't exist, it can't very well be executed.
- Is the target program NOT writable by anyone
else?
We don't want to give anyone other than the owner the ability
to change the program.
- Is the target program NOT setuid or setgid?
We do not want to execute programs that will then change our
UID/GID again.
- Is the target user/group the same as the program's
user/group?
Is the user the owner of the file?
- Can we successfully clean the process environment to
ensure safe operations?
suEXEC cleans the process' environment by establishing a safe
execution PATH (defined during configuration), as well as only passing through those
variables whose names are listed in the safe environment list (also created during
configuration).
- Can we successfully become the target program and
execute?
Here is where suEXEC ends and the target program begins.
All information came from www.apache.org
|
