idallen

You can request ssh (Secure Shell) access to your account. That will let you use the secure "scp" program.

PHP files are not themselves executable scripts, they merely *contain* bits of executable script. Thus, PHP files do not need 755 (rwxr-xr-x) permissions; mode 644 (rw-r--r--) will do nicely. CGI scripts *are* executable; they do need execute permissions (e.g. 755).

Post removed. Whilst I don't mind open discussion about security in the forums, we should make sure that potential hacking methods are not discussed in open forums. No need to feed fuel to the script kiddies of the world. Please keep this type of discussions to Private Messages.

You can request ssh (Secure Shell) access to your account, which will let you use secure copy programs. That's how I update my info here and at other cPanel sites. I will not use FTP anywhere!

I've used a Wiki on a cPanel site via the CGI::Kwiki Perl module. http://www.kwiki.org/ It works.

>I want to give some of the board members access to edit several pages >for their individual neighborhoods, without giving them full access to >editing all pages on the site. This can't be done with complete safety. The suggestion to use FTP accounts with separate subdomains only gives you casual protection from your board members. FTP or Web access restrictions do not apply to CGI scripts running in your account; any of your FTP users can write and upload executable CGI scripts that can read, delete, rename, or modify anything in your account, including files outside your public_html web directory and even the public_html directory itself. As long as your board members don't deliberately want to access the rest of your site, you're fine with a subdomain and FTP account. Don't give out FTP accounts if you're really concerned about keeping the rest of your site protected from possibly untrustworthy people. Using CGI scripts, those FTP users can do anything to your account that you can do.

None of the TCH servers are affected - they all run Linux! Yay!

That's not the only thing we have to remember. Some say that about products made by forced child labour. Yea, it's everywhere and it's really cheap; but, is that the sole measure of whether you should spend your money on it? Can you really suspend all judgement about your purchase just because it's cheap? Microsoft has been convicted of illegal and monopolistic trade practices. They didn't think their product could succeed on its own merit; they knew they had to do illegal things to prop it up and remove competition. Microsoft was found guilty. They do not "play well with others". Call me a child of the 1960's; but, that's not the kind of company I want to support. I care about where I spend my money. I didn't choose my wife based on the cheapest or easiest model available, and I don't choose my computing platform that way either. I've thought about where my money will go, and I will avoid supporting an economic bully as best I can. Sending money to a bully just makes a bigger bully. The moral and ethical damage a company does is not reflected in its share price or in the purchase price of its product offerings. That's not what I want. If you have a T-Rex dinosaur bully in the same economic system as a fellowship of cooperative ants, the T-Rex dominates. Big deal. I'm a cooperative, fellowship kind of guy - I side with the ants. If sheer numbers were a measure of goodness, we'd all mimic a hundred billion common house flies and eat dung - they don't think about where their product comes from either! Yuck!

No. Unix doesn't care what the permissions on a file are when you want to remove it. In fact, you can't remove a file. The only thing you can do in Unix is remove the *name* of a file from a directory. Files may have several names. When all the names are gone, the *system* removes the file and frees up the space. Since removing a name from a directory is a directory operation, not a file operation, the only thing that matters is the permissions on the directory containing the name. Unix doesn't care whether or not you have any permissions on the file. All that matters is that the directory lets you remove the name. For that, you need Write and Execute (search) permission on the directory. (e.g. 333 or 777 on the directory will do it.) If the userid of the person doing the removing matches the owner of the directory, permissions 7xx are all that is needed. If the userid doesn't match, you the directory must have "general" permissions, e.g. xx7. Directories with general permissions are accessible by Shell, CGI, or PHP scripts written by anyone on your server - they are not private. Be careful.

># -IAN! idallen@idallen.com set no bouncemail poll pop1.somewhere.ca with proto POP3 user abcd0001 there with password "password" is idallen@idallen.com here options no rewrite options antispam -1 poll inmail.elsewhere.com with proto POP3 user xyzzy001 there with password "passwoord" is idallen@idallen.com here options no rewrite options antispam -1

Maybe Scott can chime in here, but...I had my family geneology charts in a directory called /family on my space, but there was no link to or from my main site. Lo, there started appearing Google search hits to my family pages. Hmmmmm. Google can't find the page unless some link exists to it. That link doesn't have to be a link in *your* web space, it can be a link made by someone else. For example, you may have sent your link to some family member who mentioned it in some online chat with someone, and the chat was web-visible to Google. Or maybe someone in your family accidentally linked to your site while building their own site. All it takes is one link...

If there are no links to the hidden page, even the search engines can't find it. There is no need for the robots.txt block on files that have no links to them. If you were trying to prevent the indexing of a particular file, the trailing slash on the file name in your example may prevent the block from working. Remove the slash.

>Linux is a PITA as a desktop OS. Compared to Windows, yes. And democracy is a PITA compared to one-product totalitarian societies, and for many of the same reasons. I choose the PITA. The rest of you *will* be assimilated. :-)

> I don't believe that there is such thing as 100% security. I agree. Thumbs Up However, unlike MySQL injection, which is a security hole caused by poor programming (i.e. broken security due to a bug in the code), the lack of PHP password and file security isn't a bug - it's a (mis-)feature of the way PHP works on shared servers and no amount of careful PHP programming on your part can fix it. It's not a lock with a faulty tumbler; it's a lightly hidden back door with no lock at all and no means of installing one. A properly-written CGI implementation has no such built-in holes. When you use PHP, the risk is that someone on your server will walk through the unlocked door, or someone will find a bug in your PHP code. When you use CGI, the only risk is that someone will find a bug in your CGI code. There are no back doors that cannot be locked. As long as shared-host PHP users are aware of the extra risk that they take, everyone can make that democratic decision themselves. As you say, despite the higher risk inherent in using PHP, the considerable ease of using PHP may still outweigh the danger. My particular concern is that people be made fully aware of the risks and benefits so that they can make their own informed decisions. As a long-time system administrator and total PHP newbie, I'm most familiar with the Dark Side. Your superior PHP skills provide an excellent contrast to that and demonstrate the fun and cool things that PHP can do. I think we cover the range pretty well between us!

It's already a brand name for server watching software. We used an early free version of it on the Ottawa FreeNet when I was sysadmin: http://www-services.ncf.carleton.ca/bb/bb.html The overtones are a bit dark; but, it's certainly the right kind of name.

Nothing that uses PHP to access disk-based private data can be made secure (unless your server runs PHP in safe_mode, or if you're willing to ask the web user for the password every time). If you write some PHP script that calls your CGI script, someone else on your server can read your PHP, copy and modify it, and run your CGI too, using their data. Anything you can do with PHP and CGI, they can do too. Your privacy and control starts at the point where you call your own CGI script; from then on, the CGI script itself and all the files it accesses can be private - owned by you and only readable/writable by you. The CGI scripts can contain or reference the passwords needed to access your protected database. You have no control over who calls your CGI script or what data gets passed to it; so, your CGI script has to do all your data validation and processing. If you use your CGI to grab and return a saved password, anyone on your server could use your CGI to grab and return the same password; this is not secure. Your CGI must receive user input, process it properly, then access your protected files in a controlled way and not divulge how it does it. If you can structure your PHP to use your own CGI scripts in a controlled way, yes, it's the best safety you can get on a shared server. If you do stay with PHP only, rememember that you are only exposed to people (1) who are on the same server as you, (2) who know how to write PHP or CGI scripts to access your files, and (3) who care enough about your data to bother. With luck, not many people will bother.

metric

BigBrother

Yea - I can get those figures from Windows if I don't use the computer. Goof

You can use CGI scripts instead of PHP. CGI scripts run as *your* userid, not the userid of the web server. You can put anything you want in files and directories that are set to only be readable by you (or by CGI scripts running as you). The script you write determines what you want people to see; the files are safe from viewing by others. I don't yet know how to connect to a database using CGI; but, I'll probably look into it later this summer. Maybe others can fill in those details?

All files accessible from PHP are accessible from PHP, CGI, or shell scripts written by anyone who shares the server on which you are hosted. If your PHP script can read the keys file, so can a script written by anyone on your server (if they know where the file is). Don't use PHP or .htaccess passwords for sensitive information on a shared server. http://www.totalchoicehosting.com/forums/i...indpost&p=21336

On server20 (probably the same in all cPanel sites): DirectoryIndex index.html index.wml index.cgi index.shtml index.jsp index.js index.jp index.php4 index.php3 index.php index.phtml index.htm default.htm default.html home.htm

Redirects are "advice" from the web server to the client. In this case, since the client is not a web browser (it's a malicious piece of worm code), the client will not follow the redirect. Attacks against Microsoft software won't work here on TCH. TCH runs Linux. Rock Sign

... except perhaps good old Unix (Linux) vi !

Since your original question was about chown; but, your most recent comment talks only about chmod, I'm not sure to what "whether we can do this" refers. Only the Unix super-user can change the ownership of anything. You can't. Only the owner of a thing can use chmod on the thing to change the permissions. You can change permissions on files that you own using the cPanel interface or using chmod or chmod-like commands in CGI/PHP/shell scripts.