Gossamer Forum
Home : Products : Gossamer Mail : Discussion :

[BUG REPORT 2.1.0] Permissions created by the scripts in msgs: nobody!

Quote Reply
[BUG REPORT 2.1.0] Permissions created by the scripts in msgs: nobody!
Hello GT Staff!

I noted that the inconsistency.pl reported more and more consistencies over a period of time. Investigating it further, I found out that the directories of the first hierarchy were created the right permissions with the correct owner. Thereafter all the other directories were user nobody.

The provider is now a lot sick of changing permissions created by GT scripts. It is not possible to change owner of all the directories. May be there is a script available, or that could be integrated with the distribution for this problem.

Further, there are hundreds of messages in the disk but not in the database and there thousands of messages in the database but not on the disk. For both the cases, users do not exists. The inconsistency.pl does not work on the ghost remainders of messages because the user nobody is a bigger ghost that the Inconsistency.pl is not able to fight with.

I have reported the problem with this several months ago, most likely a year ago, that GT should offer some kind of better database integrity tool, which has remained more of a joke than a wishlist.
Quote Reply
Re: [rajani] [BUG REPORT 2.1.0] Permissions created by the scripts in msgs: nobody! In reply to
In Reply To:
I noted that the inconsistency.pl reported more and more consistencies over a period of time. Investigating it further, I found out that the directories of the first hierarchy were created the right permissions with the correct owner. Thereafter all the other directories were user nobody.

The owner of these files should be the user that Gossamer Mail runs as. In your case, it looks like your ISP has CGI's running as nobody. Any file that Gossamer Mail creates should be owned by this user or it won't be able to delete the files when it needs to. In the case of the data directory, this means more inconsistencies (user deletes email, email gets removed from database, but can't be removed from disk because file permissions were changed so that the user 'nobody' can't delete the files).

In Reply To:
The inconsistency.pl does not work on the ghost remainders of messages because the user nobody is a bigger ghost that the Inconsistency.pl is not able to fight with.

inconsistency.pl does work. I just completed a massive user purge on a huge Gossamer Mail install, followed by an inconsistency.pl run (it like 5 days to finish!). It fixed all the inconsistencies due to the manual user purge. Only problem I've run into is that sometimes the session.def file has an incorrect relation in it (session_user_id => 'user' instead of being session_user_id => 'email'). I've yet to look into it, but I believe that's due to an upgrade bug.

The problem that you're really having are permissions issues. Though, I'm looking at my data/msgs directory and the directories are chmod 777, which would allow your user to remove files from the directory. Have you changed the permissions of the directories (not ownership, but permissions)? By default, all the directories and files in the msgs directory should be 777, which would allow you as your user to delete these files (what inconsistency.pl needs to do).

Adrian
Quote Reply
Re: [brewt] [BUG REPORT 2.1.0] Permissions created by the scripts in msgs: nobody! In reply to
Hello Adrian!

Thanks for the reply.

After running the script consistency.pl, I realized that there are hundreds and thousands of inconsistencies. The last run was a few months ago. The script could not continue this time besause it said that it could not unlink one file name. Reason permission deneid.

Hence I tried to check that file out. There was only one file but not file.1 which is usually the case resulting from the MD Checksum. Anyway, I tried to delete it manually. The user did not exist as I found it from the content of that file in it. I could not delete it. Only that directory has the per 755! However, I tried to change the per. to 777 but could not. Then I tried to change the per. of all the other directory but could not.

Funny. All the per. of the first Hierarchy has the correct owner and permission. The second level all of them has user nobody, without exception. The only directory which has 755 user nobody was the reasonn of the crash.

Thats the problem. I have never done any changes nor intend to of this kind of owner per. games. It has truely resulted out of the script which I found out due to the consistency.pl.

Can it be that the original installation scripts were correct owner and the upgrade made it run as nobody? If thats the case, I could figureout by deleting the user.cgi etc. However, I do not beleive this becasue on my server, I need need to run all cgi-install scripts under cgiwrap. This I have done without exception.

The problem is not the permission but ownership. I cannot change the ownerships because there is the user nobody owning it. I cannot change the permissions because I am not the owner, which is what I did the first. The question is if there is a script or possible to make one fast to change sequencially all the directories for changing the owner, so that I can delete thousands of messages hanging around occupying the disk space. I beleive it would be asking too much my ISP for changing so many directories the ownership.

You have everything working correct because the ownerships are correct. But thats not in my case.
Quote Reply
Re: [brewt] [BUG REPORT 2.1.0] Permissions created by the scripts in msgs: nobody! In reply to
Hello Adrian!

Sorry for being inconsistent about inconsistency.pl.

The real name of that file is consistency.pl!
Quote Reply
Re: [rajani] [BUG REPORT 2.1.0] Permissions created by the scripts in msgs: nobody! In reply to
In Reply To:
The problem is not the permission but ownership. I cannot change the ownerships because there is the user nobody owning it. I cannot change the permissions because I am not the owner, which is what I did the first. The question is if there is a script or possible to make one fast to change sequencially all the directories for changing the owner, so that I can delete thousands of messages hanging around occupying the disk space. I beleive it would be asking too much my ISP for changing so many directories the ownership.

Hi Rajani,

It sounds as if your host had a cgi-wrapper running at one point but disabled it, or vise-vera. The only thing that I can think of is to ask your host to chown all the files & directories to user 'nobody' if they no longer use a cgi-wrapper or change them all to the proper user if they do use a cgi-wrapper.

In most cases, the olny user that can chown files and directories is root. That means that it isn't GMail that changed ownership on the files and dirs.

You should be able to delete files and dirs owned by 'nodody' with fileman (as long as you're not using a cgi-wrapper) and files owned by the normal user with a FTP client.

This probably isn't the answer you were hoping for but I hope it helps.

Regards,
Charlie
Quote Reply
Re: [Chaz] [BUG REPORT 2.1.0] Permissions created by the scripts in msgs: nobody! In reply to
Hello Charlie!

Do you know what is cgi-wrap?

cgiwrap is a "script wrapper" that lets your scripts execute under your own userid and group instead of user nobody and group www. As an added benefit, cgiwrap can also make the standard error output of your scripts visible through your Web browser. This is often very useful for debugging.

So when I run the wrapper under my username, how do you suggest that my provider de-activated? If he did then the wrapper would not run, right? Since the Gmail scripts got installed means that the wrapper used my user name to install the script.

Thats the case too. All the first level directories and scripts has my user id.

The second level directories in the msgs does not have my user id but nobody. This are the directories that have been created by the gmail scripts after getting the MD checksums and allocating the file names, like for e.g. 0/1/f/absiydu346fsdgv934sudtu. So 0 is my user id and 1 is user nobody. Strange phenomenon.

I beleibe that user nobody could delete files that belongs to user nobody, instead of asking the provider for a massive work. There are hundreds of them. The dir cannot be deleted because now they are there and they should remain and they contain the data.

It is a thought if there is a possibility to convert consistency.pl ir use it in such a way that it is able to delete the files that are not necessary. Also a ppreventive measure needs to be taken for this not to happen in the future.

I would be pleased if some users could also check if they have such a problem that the second level dirs are user nobody.