 | Start a set with this search |
 | Include this search in one of my sets |
 | Exclude this search from one of my sets |
 | Permalink to these results Paste this link in email or IM: |
 | Atom feed for tracking future search results Paste this URL into your reader: |
9 messages in net.sourceforge.lists.courier-maildropRe: [maildropl] per-user uid & ldap| From | Sent On | Attachments |
|---|---|---|
| Adam Divak | Apr 9, 2007 2:58 pm | |
| Petri Riihikallio | Apr 10, 2007 3:12 am | |
| Adam Divak | Apr 10, 2007 7:21 am | |
| Petri Riihikallio | Apr 10, 2007 9:43 am | |
| Divák Ádám | May 5, 2007 4:35 am | |
| Petri Riihikallio | May 5, 2007 10:29 am | |
| Divák Ádám | May 5, 2007 11:44 am | |
| Petri Riihikallio | May 7, 2007 9:14 am | |
| Divák Ádám | May 7, 2007 3:40 pm |
| Permalink for this message Paste this link in email or IM: |
| Permalink for this thread Paste this link in email or IM: |
| Atom feed for this thread Paste this URL into your reader: |
| Subject: | Re: [maildropl] per-user uid & ldap | Actions... |
|---|---|---|
| From: | Divák Ádám (epe...@near.hu) | |
| Date: | May 7, 2007 3:40:29 pm | |
| List: | net.sourceforge.lists.courier-maildrop | |
Petri Riihikallio wrote:
If the path returned for HOMEDIR doesn't exist even root or mail won't be able to change to it, never mind the permissions.
Of course the correct HOMEDIR value was returned from the LDAP server, so that was not a problem. When testing with IMAP it gave the same error: "chdir([path]) failed!!"
Without any more evidence I suggest the following:
Grep the sources for the error message. You might even want to change it slightly (add dash, dot or something), recompile and verify that you found the right spot in the source. Then scroll backwards in the source code and see what was tested. Most probably there is a quite clear "if(some system call(supplied path))" a few lines before the error message. Then you need to figure out why it is returning something that causes the error message. You may want to add a log line that prints the supllied homedir and the effective uid to the logs to verify that they indeed are what you expect.
This is the way I have debugged some mysterious error messages in open source code. Usually I have found out that my own stupidity outsmarts me by large. I am not a C-genius, there are ample examples of logging in the code. Just cut, paste and edit a bit. Be careful with the parenthesis and semicolons, they can cause even more mysterious output from the compiler.
You might even try to create your own "Hello world" type of program that calls the same system call with a fixed string and prints the output. The only challenge is to find which header files and libraries to include, but man pages are your friend.
-- Cheers Petri GSM +358 400 505 939
What you suggest seems quite reasonable but before that I share what I've found so far so maybe you recognize the missing part. Let's simply call the mail directory of user x /mail/x. /mail/x is owned by user x, group x, and user mail is member of group x.
(To avoid the "Home directory owned by wrong user" error message I've uncommented the related if statement in the source and recompiled maildrop. The code I got rid of was (main.C, line 673): //if ( buf.st_uid != getuid()) // tempfail("Home directory owned by wrong user."); so it does not harm anything else.)
With the permission settings of 770, 'su mail' and after that 'ls /mail/x' does give the right output. Just to make sure I've checked that the same command with a permission setting of 770 does fail as expected.
As in the end the 770 setting would be the desired one for the maildirs I set that and got the plain old "maildrop[25312]: Unable to change to home directory."
Now I gave 775 permissions to the /mail/x directory but left the subdirectories untouched as this gave me the possibility to use the mailfilter file as my debug source. (If maildrop can't cd to $HOME it doesn't interpret the maildroprc file)
First I entered `whoami > /1` int /etc/maildroprc and it resulted in 'mail' as expected, then `echo "$HOME" > /1` and it gave the right directory. Meanwhile maildrop complained about 'maildrop[25391]: Unable to create a dot-lock.' Remember, /mail/x is 775 and the subdirs are 770 so maildrop is treated as "others".
To prove this I entered `ls $HOME/cur > /1` in /etc/maildroprc and it resulted in 'Command output: ls: /data/mail/s/subterra.hu/admin/cur: Permission denied /usr/bin/maildrop: Unable to create a dot-lock. '
As I used a simple shell to locate the problem I think there is no need to play with altering the source.
Putting the pieces together leaves my mind in fog so I tried a few more things.
I changed the group of user mail to group x (so mail is now member of x insted of group mail) and changed LDAP_GLOBAL_GID to x accordingly. I left the permissions of the directories untouched and added an extra `touch 1` to the ls command in maildroprc. The result? The shell command run without problem BUT maildrop still complained about not being able to create a dot-lock.
This is the point where I get clueless and start to think there lies some design limitations which I'm not aware of. If anyone has an idea what stupidity I made please let me know
Thanks, Adam