[Dovecot] mail accounts for users without home dirs
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hi!
I use dovecot on a machine where users without an existing home directory (Not my idea...) need to access their mailboxes. Unfortunately dovecot tries to chdir to the users home directory before allowing IMAP access - is there anything I can do about that besides creating a dummy-homedirectory for these users?
Greetings,
Gunter
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ the arrow is being aimed between your eyes. -- (Terry Pratchett,
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Chain-mail isn't much defence against an arrow. It certainly isn't whenPGP-verschlüsselte Mails bevorzugt! +
Lords and Ladies) +-+-+-+-+-+-+-+-+-+-+-+-+ http://www.lspace.org +-+-+-+-+-+-+-+-+-+-+-+-+ -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.2 (GNU/Linux)
iD8DBQE/SpA/0ORHvREo8l8RAvFcAJ0ZsnnRTmBUzQEuon6QLDSOWMB2lgCfVFJw C/6nmMXb8cyvOWog0cfmi6E= =iO/e -----END PGP SIGNATURE-----
On Tue, Aug 26, 2003 at 12:39:42AM +0200, Gunter Ohrner wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hi!
I use dovecot on a machine where users without an existing home directory (Not my idea...) need to access their mailboxes. Unfortunately dovecot tries to chdir to the users home directory before allowing IMAP access - is there anything I can do about that besides creating a dummy-homedirectory for these users?
I have a similar set up; none of the mail accounts correspond to an account in my passwd file. I have a postoffice account in the passwd file that owns the /var/mail directories where mail is stored. I use LDAP to assign each user the UID number for the postoffice account so that Dovecot's imap process can work with their mail. The postoffice home directory receives the raw log entries, and the account runs some related cron jobs that help manage the mail. So basically, I have one Unix account and home directory to handle all mail users. If you don't want to deal with LDAP, you should be able to do something similar with PgSQL, or perhaps one of the other supported user databases. The key is always passing the postoffice UID number to Dovecot, regardless of the user.
Bob Hall
I use dovecot on a machine where users without an existing home directory (Not my idea...) need to access their mailboxes. Unfortunately dovecot tries to chdir to the users home directory before allowing IMAP access - is there anything I can do about that besides creating a dummy-homedirectory for these users?
I have a similar set up; none of the mail accounts correspond to an account in my passwd file. I have a postoffice account in the passwd file that owns the /var/mail directories where mail is stored. I use LDAP to assign each user the UID number for the postoffice account so that Dovecot's imap process can work with their mail. The postoffice home directory receives the raw log entries, and the account runs some related cron jobs that help manage the mail. So basically, I have one Unix account and home directory to handle all mail users. If you don't want to deal with LDAP, you should be able to do something similar with PgSQL, or perhaps one of the other supported user databases. The key is always passing the postoffice UID number to Dovecot, regardless of the user.
You can accomplish this with the static userdb:
auth_userdb = static uid=210 gid=210 home=/var/mail/%d/%n
...or something to that effect.
-- Alex Howansky Wankwood Associates http://www.wankwood.com/
On Thu, 2003-08-28 at 03:34, Alex Howansky wrote:
You can accomplish this with the static userdb:
auth_userdb = static uid=210 gid=210 home=/var/mail/%d/%n
Of course, I don't really suggest of using just one uid for everything.. Preferrably each user should have separate one, or at least one for each domain or other group of users that "trust" each others.
On Thu, Aug 28, 2003 at 04:00:11AM +0300, Timo Sirainen wrote:
On Thu, 2003-08-28 at 03:34, Alex Howansky wrote:
You can accomplish this with the static userdb:
auth_userdb = static uid=210 gid=210 home=/var/mail/%d/%n
Of course, I don't really suggest of using just one uid for everything.. Preferrably each user should have separate one, or at least one for each domain or other group of users that "trust" each others.
Let's say you have one server box and 20 users. Only the admins have accounts on the server box. Users can access mail only through the mail servier, via port 143. This involves three types of Unix accounts: root, human admins, and the non-human mail account that owns the mail files and runs mail scripts. Use sudo to give the admins the right to perform any necessary tasks that need the mail account, so that the mail account password doesn't get passed around.
- What are the security weaknesses?
- How does having one UID differ from having one password that gives you access to all the UIDs in the database?
- How is this handled in settings with hundreds of users? Do they create hundreds of Unix accounts?
Sorry about all the questions, but I'm trying to get a better understanding of security.
Bob Hall
On Thursday, Aug 28, 2003, at 06:05 Europe/Helsinki, Bob Hall wrote:
Let's say you have one server box and 20 users. Only the admins have accounts on the server box. Users can access mail only through the mail servier, via port 143. This involves three types of Unix accounts: root, human admins, and the non-human mail account that owns the mail files and runs mail scripts. Use sudo to give the admins the right to perform any necessary tasks that need the mail account, so that the mail account password doesn't get passed around.
- What are the security weaknesses?
With shared uids the problem is that if there's a security hole in Dovecot, attacker can access all the files that are owned by his uid. So different uids just provide operating system level security.
- How does having one UID differ from having one password that gives you access to all the UIDs in the database?
If you know the password, it doesn't differ. If you don't, but you could exploit security hole in Dovecot you then have access.
- How is this handled in settings with hundreds of users? Do they create hundreds of Unix accounts?
They don't have to have real accounts, just the uids have to be reserved for them. For example you could just decide that uids above 10000 are for virtual users in LDAP.
On Thu, Aug 28, 2003 at 06:50:18AM +0300, Timo Sirainen wrote:
On Thursday, Aug 28, 2003, at 06:05 Europe/Helsinki, Bob Hall wrote:
Let's say you have one server box and 20 users. Only the admins have accounts on the server box. Users can access mail only through the mail servier, via port 143. This involves three types of Unix accounts: root, human admins, and the non-human mail account that owns the mail files and runs mail scripts. Use sudo to give the admins the right to perform any necessary tasks that need the mail account, so that the mail account password doesn't get passed around.
- What are the security weaknesses?
With shared uids the problem is that if there's a security hole in Dovecot, attacker can access all the files that are owned by his uid. So different uids just provide operating system level security.
- How does having one UID differ from having one password that gives you access to all the UIDs in the database?
If you know the password, it doesn't differ. If you don't, but you could exploit security hole in Dovecot you then have access.
- How is this handled in settings with hundreds of users? Do they create hundreds of Unix accounts?
They don't have to have real accounts, just the uids have to be reserved for them. For example you could just decide that uids above 10000 are for virtual users in LDAP.
Since the UIDs don't correspond to actual system accounts, then I take it that there's no OS level security? So if you have a requirement for stringent security, you can't use large scale mail systems? Multidrop boxes must have the same weakness.
Bob
On Thu, 2003-08-28 at 10:01, Bob Hall wrote:
They don't have to have real accounts, just the uids have to be reserved for them. For example you could just decide that uids above 10000 are for virtual users in LDAP.
Since the UIDs don't correspond to actual system accounts, then I take it that there's no OS level security?
There is. With unix accounts I mean about having the user in /etc/passwd or equilevant. Kernel doesn't care about that, it only cares about the uids used for files and processes.
On Thu, Aug 28, 2003 at 10:18:48AM +0300, Timo Sirainen wrote:
On Thu, 2003-08-28 at 10:01, Bob Hall wrote:
They don't have to have real accounts, just the uids have to be reserved for them. For example you could just decide that uids above 10000 are for virtual users in LDAP.
Since the UIDs don't correspond to actual system accounts, then I take it that there's no OS level security?
There is. With unix accounts I mean about having the user in /etc/passwd or equilevant. Kernel doesn't care about that, it only cares about the uids used for files and processes.
I thought that the OS used UIDs to associate files and processes with passwd accounts. So if you pass Dovecot a UID that doesn't correspond to the account that owns the mail files, then you don't get access to the mail files. For example, when I passed one account UID number to Dovecot, and the mail files were owned by another account, access was denied. Are you saying there's a work-around?
Bob Hall
On Thu, 2003-08-28 at 11:04, Bob Hall wrote:
There is. With unix accounts I mean about having the user in /etc/passwd or equilevant. Kernel doesn't care about that, it only cares about the uids used for files and processes.
I thought that the OS used UIDs to associate files and processes with passwd accounts. So if you pass Dovecot a UID that doesn't correspond to the account that owns the mail files, then you don't get access to the mail files.
The point was that the mail files are owned by the same uid that is running imap process. It doesn't matter if the uid is in passwd-file or not, it's just ls, ps and other userspace programs that map uids to usernames using it.
So you would have to have same uid <-> username maps for Dovecot and SMTP server, but they don't have to be anywhere else.
participants (4)
-
Alex Howansky
-
Bob Hall
-
Gunter Ohrner
-
Timo Sirainen