Gossamer Forum
Home : Products : Gossamer Mail : Discussion :

Isn't this a Security Threat?

(Page 2 of 2)
> >
Quote Reply
Re: [Paul] Isn't this a Security Threat? In reply to
Paul you as a 'Veteran' can definitely insist on that but I as an 'Enthusiastic' user only wants to get this headache lessened.

Due to a recent contract signed with one of shared hosting client I can all the more not give access to server as this client is taking 5 GB. As a businessperson i cannot afford to annoy this client.

In fact i have never seen any bug fixes on GM in "official Bugfixes" forum. Probably GM is becoming less important with passage of time....

Anup
Post deleted by anup123 In reply to
Quote Reply
Re: [Paul] Isn't this a Security Threat? In reply to
750 and this is what i get:

You don't have permission to access /cgi-bin/....../admin.cgi on this server.

So back to 751 now.

Any suggestions....

Anup
Quote Reply
Re: [anup123] Isn't this a Security Threat? In reply to
Quote:
In fact i have never seen any bug fixes on GM in "official Bugfixes" forum. Probably GM is becoming less important with passage of time....

This is where I think GT should implement something like Bugzilla to track bugs and fixes. All bugs and fixes are in one spot for any given product. Right now, it's scattered at best here in the forum and the "official Bugfixes" forum doesn't seem to be used for all products like you mentioned.

As long as GT is fixing bugs in CVS, I'd like to see registered users have access to a current cvs snapshot of products they own as well as the last stable release in the download area.

~Charlie
Quote Reply
Re: [Chaz] Isn't this a Security Threat? In reply to
Quote:
You are correct in that a user wouldn't be able to access a file from a shell but it won't prevent a hacker from writing a perl script (to rus as nobody from a browser) and getting at the def files.

All in all, the results are the same, security is compromised, the hacker just used a different door to walk through.

Well sure, but then I could say even if permissions were perfect I could guess anup's ftp password and delete his site.
Quote Reply
Re: [anup123] Isn't this a Security Threat? In reply to
Quote:
Paul you as a 'Veteran' can definitely insist on that but I as an 'Enthusiastic' user only wants to get this headache lessened.

I'm trying to help with that. If I wasn't I wouldn't have tried to clearly explain the situation with permissions/ownership.
Quote Reply
Re: [Paul] Isn't this a Security Threat? In reply to
Sure, that is true. But it is certainly not as easy as writing a perl script to read the files. Any server can be compromised given the right tools. I just prefer to hide the tools in the bushes and not leave them sitting outside the front door :)

~Charlie
Quote Reply
Re: [Paul] Isn't this a Security Threat? In reply to
Quote:
I'm trying to help with that. If I wasn't I wouldn't have tried to clearly explain the situation with permissions/ownership.

Sure I know. 750 did not help and in fact long back the service provider had communicated that isp's are normally paranoid setting 750.

750 did not work in my case as suggested by you.

Thnx
Anup
Quote Reply
Re: [Chaz] Isn't this a Security Threat? In reply to
Quote:
But it is certainly not as easy as writing a perl script to read the files.

You'd have to hack the server in order to run the perl script. I very much doubt anyone is going to hack your server just to read your GT def files. If they were able to hack your server they'd probably install a root kit and run an IRC bot or something - defs would be the last thing on their mind :)

Last edited by:

Paul: May 4, 2003, 2:30 PM
Quote Reply
Re: [Chaz] Isn't this a Security Threat? In reply to
Would following be any way detrimental to operation of GM as a workaround against the ability to read the content of def files:

chmod the admin (under which is the defs directory) directory to 750.

If the above would not be possible then the only way would be to disallow cat/more/less to users for the time being.

Anup
Quote Reply
Re: [anup123] Isn't this a Security Threat? In reply to
Like Paul mentioned, a user shouldn't be able to view the files from a shell. Diabling cat/more/less isn't going to help too much.

~Charlie
Quote Reply
Re: [anup123] Isn't this a Security Threat? In reply to
Could you try chown/chgrping the files to your username instead of nobody?
Quote Reply
Re: [Paul] Isn't this a Security Threat? In reply to
Pual I did 750 to admin and now a user can't go to defs directory.

So far i have not noticed anything abnormal. Do U perceive any problem on 750 to admin directory (under which the defs directory exists?

chown nobody to mylogin the full GM install you mean or which part of it? Actually the bugs on my install (purge; admin/validate delete etc) makes me fearful of doing any changes to what GT staff/installer have done for installation. I never know what can trigger new set of bugs which may be dormant so far and cripple the install altogether. That would be a pretty suicidal scenario if it happens.

Anup
Quote Reply
Re: [anup123] Isn't this a Security Threat? In reply to
I replied in the other thread, where you were complaining about not being able to get your problems solved, but not being willing to allow GT to see the problems, as well. You got the same response from others in this thread, as well.

But, here, you say:

Quote:


Alternatively, GT could ask for the components that they suspect to be culprit/ bug infected which can be willingliy sent by users like me. Afterall it ought to be some component(s) which may be responsible....and not the whole program. Sometimes the problem may not be reproduced at their end because they would be ruuning components which aren't packaged in the install (cf user.pm case).


They have the components. They do not have the same server layout as you, and the _ONLY_ way they can see what is wrong with _YOUR_ server/installation is to see it RUNNING (or not running) on _YOUR_ server.

If you refuse to allow them access, whining about it here (and that is what you are doing), is to _NO_ avail to anyone. It will _NOT_ get the problem fixed, and it will annoy forum visitors (like me) who have to read it.

Paul has gone out of his way to try to help you with _UNIX_ issues, not even related to GT products, and you seem to not truly appreciate that either.

One more thing that bothers me, is why you say ISP's "paranoid" about setting 750 permissions? The _only_ problem this would cause is ti "break" installs by not allowing users to access the file, and for a directory, under Apache, it could "break" the ability to access any files in, or below that directory. But "paranoid" about it, why??? Paranoid would be setting 777 on a home directory, or running script, or not running shadow passwords.

I'm not sure I want an answer, because I'm not sure I can stomach more of this stuff. I sympathize with your frustrations, but until, and unless, you give GT access to see/fix the problems, ranting and raving, whining and complaining, and all this other stuff is quite pointless. It helps no one.

Quote:

Suggestion Made: If you have a serious problem, you might be better off using the Support Request Form.

Your response: Actually the difficulty is that i cannot give access to server so even support request form doesn't work.

This is your choice, and if you refuse to use the tools that GT has set up, and in place to fix, correct, and solve the problems, live with that decision -- silently ***PLEASE***

No other company I have dealt with goes as far as GT to fix, solve, and deal with problems that arise with their programs. If you want to tie their hands, that's your choice. They are way too busy supporting other customers who are willing to meet them halfway, and in developing new products, to try to track down phantom bugs that may be your server's problem, not theirs at all.

I guess I said my piece. But I know I came here to find support/answers, and I know I can't be alone in how I feel about reading these threads. I just happen to not be shy about posting my feelings, and my overall _very_ positive interactions with (and observations of) GT's handling of bugs and issues with their programs.


PUGDOG´┐Ż Enterprises, Inc.

The best way to contact me is to NOT use Email.
Please leave a PM here.
Quote Reply
Re: [pugdog] Isn't this a Security Threat? In reply to
Quote:
I guess I said my piece. But I know I came here to find support/answers, and I know I can't be alone in how I feel about reading these threads. I just happen to not be shy about posting my feelings, and my overall _very_ positive interactions with (and observations of) GT's handling of bugs and issues with their programs.

The days when i had given access it took more than this amount of so called "whining" to get through.

Quote:
Paul has gone out of his way to try to help you with _UNIX_ issues, not even related to GT products, and you seem to not truly appreciate that either.

The day i meet personally i'll touch his feet. That's the way we show regard if we have to instead of Hollow Thankyou's and Sorrys.

Quote:
This is your choice, and if you refuse to use the tools that GT has set up, and in place to fix, correct, and solve the problems, live with that decision -- silently ***PLEASE***

The server set up was seen by GT and approved much before i decided to Buy GM so that should have been taken care of (presumably) wrt peculiarities of setup.

Anup
Quote Reply
Re: [anup123] Isn't this a Security Threat? In reply to
Perculiarities can happen at any time. GT run their own hosting business with custom configured servers all verified and tweaked by GT to give the best performance but issues can still arise at any time even on those servers.

I know it's frustrating, but seriously, the only way to fix these strange bugs is to gain access to the server (unless this is something GT can reproduce).

It's frustrating for you, but it's also frustrating for GT too, to not be able to access the server and resolve the problem. I know from experience with scripts I've written and released. I very much want to fix bugs my customers find and Gossamer do too, but their hands are tied without any sort of first hand access.

I've tried to explain permissions best I can and to the best of my knowledge. Gossamer can only do the same, but it may still not fix anything. If you could explain what you'd like them to do without any sort of server access then I'm sure they'd try to help.
Quote Reply
Re: [anup123] Isn't this a Security Threat? In reply to
Hi,

I haven't read through this entire thread, but I'll respond to the security questions.

If you are on a shared server, it's up to your webhosting provider to provide you with adequate security from other users. We can not guarantee a Gossamer Mail install will be safe from other users on a shared server, it's simply impossible given the setup of a lot of hosts. It's up to the webhost to provide you with a safe environment for your site.

Webhosting companies can set this up in a number of ways, however sadly, it's been our experience that the majority of them do not do this. They can use technologies like virtual private servers, chroot enviornments, or just plain sensible permissions, to ensure you have a safe environemnt. A stock RedHat will _not_ be safe enviornment for multiple untrusted users.

With GossamerHost, we set things up so that it is not possible for a user to view any files within the other users home directory, so permissions on files within your home directory are not as important.

The files need to default to 666 so that Gossamer Mail will work with 90% of the ISP's out there that don't run under suexec.

Hope this helps,

Alex
--
Gossamer Threads Inc.
> >