[Dovecot] ManageSieve and invalid scriptname
Hello there,
I have been using pysieved and avelsieve and it has been working great. I decided to do test with the ManageSieve patch and got this problem:
Nov 27 17:21:29 cambui dovecot: MANAGESIEVE(miguel): sieve-storage: using active sieve script path: ~/.dovecot.sieve Nov 27 17:21:29 cambui dovecot: MANAGESIEVE(miguel): sieve-storage: using sieve script storage directory: ~/.sieve Nov 27 17:21:29 cambui dovecot: MANAGESIEVE(miguel): sieve-storage: relative path to sieve storage in active link: .sieve/ Nov 27 17:21:29 cambui dovecot: MANAGESIEVE(miguel): sieve-storage: Active sieve script symlink /home/admsis/miguel/.dovecot.sieve is broken: invalid scriptname (points to .sieve/phpscript).
Well as you can see, a file without the .sieve is not welcome :-(
I checked the RFC and there is no requirement for a .sieve file extension when considering scriptnames.
http://tools.ietf.org/html/draft-martin-managesieve-12#section-1.6
Is this a misplaced restriction or it really should be enforced for any reason?
I hope that this can be tolerable, or I will have to rename a lot of scripts and remove all hardcoded "phpscript" strings from avelsieve :-(
Regards and thanks for the great work.
Miguel
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Thu, 27 Nov 2008, Miguel Filho wrote:
Well as you can see, a file without the .sieve is not welcome :-(
I checked the RFC and there is no requirement for a .sieve file extension when considering scriptnames.
Well, the RFC specifies the scriptname "on wire", but does not (and should not) care, what happens afterwards.
You muddle with the internal storage of the managesieve demon. It contains sanity checks to prevent that its operations breaks other programs managing Sieve scripts and the other way around.
Is this a misplaced restriction or it really should be enforced for any reason?
I hope that this can be tolerable, or I will have to rename a lot of scripts and remove all hardcoded "phpscript" strings from avelsieve :-(
I guess you've configured avelsieve to place the script right into the home directory of the user rather than through ManageSieve, right? Therefore Managesieve detects that this script is alien and keeps its hands off.
Either use Managesieve (the protocol) or configure the symlinks in reverse direction (though I suppose it won't work unless Avelsieve overwrites the file):
ln -s ~user/.dovecot.sieve ~user/phpscript
So Avelsieve will manage, whatever Managesieve places there, and Managesieve does not detect the alien interference.
Another strategy would be to: a) test what happens if the target of ~/.dovecot.sieve (~/Maildir/sieve/script.sieve) is a symlink itself. b) remove the name check from the demon.
But why are you using two sieve management interfaces?
Bye,
Steffen Kaiser -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux)
iD8DBQFJL6jlVJMDrex4hCIRAo/UAJ46ftWtrmSxnrhmYEac/kpUblOLngCeLvzN Y7dXaE1cvNzPw7s/XMQOQ4s= =otoV -----END PGP SIGNATURE-----
On Fri, Nov 28, 2008 at 6:16 AM, Steffen Kaiser skdovecot@smail.inf.fh-brs.de wrote:
I guess you've configured avelsieve to place the script right into the home directory of the user rather than through ManageSieve, right? Therefore Managesieve detects that this script is alien and keeps its hands off.
No, avelsieve is a squirrelmail plugin to create a sieve script. It talks to a ManageSieve daemon, in my case pysieved. pysieved puts the scripts in ~/.sieve and links ~/.dovecot.sieve do the current script in ~/.sieve.
So Avelsieve will manage, whatever Managesieve places there, and Managesieve does not detect the alien interference.
Avelsieve doesn't manage anything, pysieved does.
b) remove the name check from the demon.
That is what I'm asking :-D
But why are you using two sieve management interfaces?
I'm not. I'm testing the ManageSieve patch and preparing to replace pysieved, because it lacks encryption and I need to open direct access to it for my users.
Regards,
Miguel
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Fri, 28 Nov 2008, Miguel Filho wrote:
So Avelsieve will manage, whatever Managesieve places there, and Managesieve does not detect the alien interference.
Avelsieve doesn't manage anything, pysieved does.
OK, so you do use two interfaces, managesieve and pysieved ;-)
But why are you using two sieve management interfaces?
I'm not. I'm testing the ManageSieve patch and preparing to replace pysieved, because it lacks encryption and I need to open direct access to it for my users.
Do the migration pysieved -> managesieve like so:
- Connect with an user without .dovecot.sieve symlink to managesieved.
- Upload a new script.
- Check where the script has been filed into.
- Then replicate the structure for each user and rename the existing file into "phpsieve.sieve" (phpsieve is the name of the script) and adjust the ~/.dovecot.sieve symlink to point there.
E.g. my real users with Maildir
- have ~/.dovecot.sieve -> Maildir/sieve/horde-ingo.sieve
- Maildir base path is ~/Maildir
- and Horde uses "horde-ingo" as script name.
Bye,
Steffen Kaiser -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux)
iD8DBQFJL93CVJMDrex4hCIRAi4EAKDDZWVuJ9EgUYiO9xOz9fMXoaWAfwCgyOyq 0Gbh/xj4c0Zb3g3pMd7X26k= =bgr0 -----END PGP SIGNATURE-----
On Fri, Nov 28, 2008 at 10:02 AM, Steffen Kaiser skdovecot@smail.inf.fh-brs.de wrote:
Do the migration pysieved -> managesieve like so:
- Connect with an user without .dovecot.sieve symlink to managesieved.
- Upload a new script.
- Check where the script has been filed into.
- Then replicate the structure for each user and rename the existing file into "phpsieve.sieve" (phpsieve is the name of the script) and adjust the ~/.dovecot.sieve symlink to point there.
That is what I'm trying to avoid.
My original problem is this: sieve-storage: Active sieve script symlink /home/admsis/miguel/.dovecot.sieve is broken: invalid scriptname (points to .sieve/phpscript).
- The link is correct
- cmusieve works fine with a link pointing to a file WITHOUT .sieve at the end.
When the ManageSieve patch follows the .dovecot.sieve link it complains that the file does not end in .sieve. So, I'm asking if there is a real point doing this restriction or the guilt is pysieved for not creating a file with a .sieve at the end.
If the pysieved is guilt, than I will have to rename all scripts already installed :-(
Regards,
Miguel
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On Fri, 28 Nov 2008, Miguel Filho wrote:
there is a real point doing this restriction or the guilt is pysieved for not creating a file with a .sieve at the end.
There is no "guilt" here. Both are independed demons for the same service.
You could put the same "guilt" to UW-imap for not storing mails in Maildir, or, when you switch from Cyrus to Dovecot, to any of the two for not use the same storage backend.
I count it as safety measurement to probe for the extension.
Bye,
Steffen Kaiser -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux)
iD8DBQFJL+0+VJMDrex4hCIRAgYjAJ4pyi9SAkFplkMMn/peE7EXcLaT2wCg2BXP bZUt9kUYtkddu7QqYisaCN4= =FmcA -----END PGP SIGNATURE-----
Miguel Filho schreef:
Hello there,
I have been using pysieved and avelsieve and it has been working great. I decided to do test with the ManageSieve patch and got this problem:
Nov 27 17:21:29 cambui dovecot: MANAGESIEVE(miguel): sieve-storage: using active sieve script path: ~/.dovecot.sieve Nov 27 17:21:29 cambui dovecot: MANAGESIEVE(miguel): sieve-storage: using sieve script storage directory: ~/.sieve Nov 27 17:21:29 cambui dovecot: MANAGESIEVE(miguel): sieve-storage: relative path to sieve storage in active link: .sieve/ Nov 27 17:21:29 cambui dovecot: MANAGESIEVE(miguel): sieve-storage: Active sieve script symlink /home/admsis/miguel/.dovecot.sieve is broken: invalid scriptname (points to .sieve/phpscript).
Well as you can see, a file without the .sieve is not welcome :-( That is correct.
I checked the RFC and there is no requirement for a .sieve file extension when considering scriptnames. True, but the ManageSieve server will not use the .sieve extension in the communication with the client. So, as far as the client is concerned, the script is called "phpscript". The client can still choose any script name it wants, it is only stored a little differently on the filesystem, which is an implementation concern and has nothing to do with the protocol RFC.
http://tools.ietf.org/html/draft-martin-managesieve-12#section-1.6
Is this a misplaced restriction or it really should be enforced for any reason? The .sieve extension is merely added for storage in the file system to distinguish it from other types of files that may reside in the same directory. Otherwise, "LISTSCRIPTS" would for instance list any file in the storage directory, e.g. also compiled binaries that result from command line execution of sievec. Also note that the .sieve extension itself is not my own invention, because it is specified in section 7 of RFC 5228.
As shown recently, this also has a limiting effect on the scope of security holes that involve accessing inappropriate directories. If I had not made this design choice, the recently discovered security hole would have given any user the ability to access any file that is accessible from the uid the server is running with. GETSCRIPT "../victim/mail/inbox.mbox" would for instance have been possible with virtual users.
So, at all times, only regular files ending with .sieve are considered to be valid sieve scripts. This is also true for the symbolic link that points to the active script. If it points to something else, it is considered to be invalid and no active script is reported in LISTSCRIPTS (a situation that is fixed automatically when a proper script is activated).
I hope that this can be tolerable, or I will have to rename a lot of scripts and remove all hardcoded "phpscript" strings from avelsieve :-( Good news and bad news here. The good news is that you will not need to change Avelsieve in any way. The ManageSieve script name "phpscript" is implicitly stored as "phpscript.sieve". And the other way around: if a script file called "phpscript.sieve" resides in the sieve storage directory it is reported to Avelsieve as "phpscript". That's where the bad news comes in: you still need to rename all existing script files from "phpscript" to "phpscript.sieve" for the Dovecot ManageSieve server to notice them. After that, you can reactivate all scripts (Avelsieve should do this implicitly) and all should work.
Hmm, maybe I should write a short migration manual.
Regards,
-- Stephan Bosch stephan@rename-it.nl
participants (3)
-
Miguel Filho
-
Steffen Kaiser
-
Stephan Bosch