Re: Home directory owned by wrong user

On 02.11.2017 12:08, Sam Varshavchik wrote:
> Norbert Harrer writes:
>
>> Thank you for your reply. And yes, you are right there has been a 
>> change in Debian. But it seems like the the other way around. Package 
>> courier-maildrop was replaced by the regular maildrop. I should have 
>> mentioned that. This was the message regarding it during upgrade: 
>> <URL:https://i.imgur.com/NZ3BsJy.png>https://i.imgur.com/NZ3BsJy.png
>
> That doesn't look right.

Yes. But I just checked again. The package courier-maildrop in Debian 
stable (stretch) is only a dummy package which contains a dependency to 
package maildrop (https://packages.debian.org/stretch/courier-maildrop), 
which itself is based on source maildrop-2.8.4.tar.bz2 from sourceforge. 
Updating courier-maildrop to the current stable version shows the 
message I posted.
Whereas in oldstable (jessie) both packages, courier-maildrop and 
maildrop, contain a maildrop binary.

>> I followed those instructions (adding parameter -d "" and enabling 
>> DEFAULT="$HOME/Maildir" in /etc/maildroprc). But even if I take those 
>> changes back I have the same problem.
>
> If that package is the non-Courier version of maildrop, this cannot work.

Yes, and in fact it didn't :-) At least not if $HOME is something 
different then the actual home in /etc/passwd.

> Correct. Only the Courier version of maildrop will trust the contents 
> of $HOME. Anything can set $HOME in the environment, so it cannot be 
> used to determine the destination account's home directory. The 
> non-Courier version of maildrop uses its userid to look up the 
> purported account's home directory, and since it's /usr/sbin, and not 
> owned by daemon, it bails out.

Aha. Thanks for explaining the difference. Now I understand why it 
worked before. Just out of curiosity. Are courier maildrop and 
non-courier maildrop a lot different? Or are they the same source just 
built with different options?

> The standalone version of maildrop doesn't know anything about 
> Courier's virtual accounts. It's a generic, non mail-server specific, 
> mail delivery agent.
>
> Now, if it has been compiled with courier-authlib separately, the -d 
> option can be used to look up the same virtual account that Courier 
> used to deliver the mail. But the same mailbox name must be passed to 
> -d, not an empty string, and maildrop needs to be invoked as root so 
> that it can drop root privileges and run under the correct virtual 
> userid.

o.O woow! That worked straight away. I replace -d ""  with -d $USER in 
DEFAULTDELIVERY in /etc/courier/courierd and now everything is happy again.

Fantastic, thank you!!


------------------------------------------------------------------------------
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot