Re: ACLs and cross-namespace move problem
On Mon, Mar 11, 2013 at 3:33 PM, Marc Patermann hans.mo...@ofd-z.niedersachsen.de wrote: Thomas, Thomas Cataldo schrieb (11.03.2013 10:21 Uhr): Note that some rights are available implicitly, for example 'anonymous' always has 'p' on user INBOXes, and users always have rights on mailboxes within their INBOX hierarchy. Do you have a link? https://cyrusimap.org/docs/cyrus-imapd/2.4.17/overview.php#acladm I think Archive should qualify as user B always has rights on mailboxes within the INBOX hierarchy, like the Archive folder. When I look at the permissions with cyradm, I have : localhost lam user/b...@willow.vmw b...@willow.vmw lrswipkxtecda admin0 lrswipkxtecda a...@willow.vmw lrswipkxtecd localhost lam user/b/arch...@willow.vmw admin0 lrswipkxtecda a...@willow.vmw lrswipkxtecda Do I mis-understand something or should I file a bug ? (I am using unix hierarchy sep + altnamespace) I think this has always been this way. If you create a subfolder it inherits the rights from the upper level and so you have the same right for INBOX and subfolders, as long as you do not change the rights. You can always revoke your own rights, I think. Moving/renaming a folder has always (as far I remember for 2.2. und 2.3) been keeping the rights with the folder. Marc The question is can we consider it a bug ? The same kind of problems happens when an IMAP client deletes a folder inside a shared folder. It renames the folder to move it to my trash and all the people that had read permissions on the shared folder start seeing Other users/me/Trash/The deleted folder in their imap clients. Another related question would be, how do you guys deal with that ? Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/ To Unsubscribe: https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
Re: ACLs and cross-namespace move problem
Thomas, Thomas Cataldo schrieb (11.03.2013 10:21 Uhr): I have a problem with shared user mailboxes and permissions on cyrus 2.4.16. User A has read/write access on user B (lrswipkxte) Folders looks like this for user A: INBOX Archive 2012 Other Users/ == the user's namespace B (user B inbox) Sent Drafts Trash User A wants to move the Archive folder to User B. He does a simple dragdrop in thunderbird for his box to Other Users/B. With its knowledge of permissions, thunderbird issues a RENAME : RENAME Archive OtherUsers/B/Archive Cyrus does not detect completely that the rename crosses a namespace boundary. The Archive folder is at the right place on the filesystem : /var/spool/cyrus/willow_vmw/domain/w/willow.vmw/b/user/b/Archive But only A has permissions on it whereas the documentation states that: Note that some rights are available implicitly, for example 'anonymous' always has 'p' on user INBOXes, and users always have rights on mailboxes within their INBOX hierarchy. Do you have a link? I think Archive should qualify as user B always has rights on mailboxes within the INBOX hierarchy, like the Archive folder. When I look at the permissions with cyradm, I have : localhost lam user/b...@willow.vmw b...@willow.vmw lrswipkxtecda admin0 lrswipkxtecda a...@willow.vmw lrswipkxtecd localhost lam user/b/arch...@willow.vmw admin0 lrswipkxtecda a...@willow.vmw lrswipkxtecda Do I mis-understand something or should I file a bug ? (I am using unix hierarchy sep + altnamespace) I think this has always been this way. If you create a subfolder it inherits the rights from the upper level and so you have the same right for INBOX and subfolders, as long as you do not change the rights. You can always revoke your own rights, I think. Moving/renaming a folder has always (as far I remember for 2.2. und 2.3) been keeping the rights with the folder. Marc Cyrus Home Page: http://www.cyrusimap.org/ List Archives/Info: http://lists.andrew.cmu.edu/pipermail/info-cyrus/ To Unsubscribe: https://lists.andrew.cmu.edu/mailman/listinfo/info-cyrus
Re: ACLs
Jt Chiodi wrote: I have noticed that a sub folder of a user's INBOX does not have anyone p set on it when it is created. I am not giving my users access to cyradm and do not want to change acls everytime a mailbox is created. I would like to set the default sub folder behavior to anyone p. I looked at the man for imapd.conf and the closest thing I can find is defaultacl but the descripion says non-user with no parent. How can I sent the default behavior of a user INBOX sub folder to anyone p If this is what you really want to do (I'm not sure that I'd appreciate the fact that an admin is unilaterally enabling anyone to post to my personal mailboxes), explicitly set 'anyone p' on the INBOX, and this ACL will be inherited by all submailboxes when they are created. -- Kenneth Murchison Systems Programmer Carnegie Mellon University Cyrus Home Page: http://asg.web.cmu.edu/cyrus Cyrus Wiki/FAQ: http://cyruswiki.andrew.cmu.edu List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: ACLs
Ken Murchison wrote: Jt Chiodi wrote: I have noticed that a sub folder of a user's INBOX does not have anyone p set on it when it is created. I am not giving my users access to cyradm and do not want to change acls everytime a mailbox is created. I would like to set the default sub folder behavior to anyone p. I looked at the man for imapd.conf and the closest thing I can find is defaultacl but the descripion says non-user with no parent. How can I sent the default behavior of a user INBOX sub folder to anyone p If this is what you really want to do (I'm not sure that I'd appreciate the fact that an admin is unilaterally enabling anyone to post to my personal mailboxes), explicitly set 'anyone p' on the INBOX, and this ACL will be inherited by all submailboxes when they are created. Hi all. What is the purpose/usage of p right? I mean, I know what it stands for, post right, giving permission to the user to post a message into that folder. So far, I have been thinking of it in terms of mail delivery, since that is what allows Cyrus to accept messages and file them into a particular folder. Am I right? So, how come only the owner of a mailbox has p? Does Cyrus switch to the owner, in case of a delivery? I know I had to give anyone p on shared folders. I tried giving p to user cyrus, but it somehow did not work, not sure why. Delivery is done from Sendmail via LMTP and I did setup auth-info, so Sendmail should have authenticated itself as user cyrus. Is that the right way? Nix. Cyrus Home Page: http://asg.web.cmu.edu/cyrus Cyrus Wiki/FAQ: http://cyruswiki.andrew.cmu.edu List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: ACLs
Nikola Milutinovic wrote: Ken Murchison wrote: Jt Chiodi wrote: I have noticed that a sub folder of a user's INBOX does not have anyone p set on it when it is created. I am not giving my users access to cyradm and do not want to change acls everytime a mailbox is created. I would like to set the default sub folder behavior to anyone p. I looked at the man for imapd.conf and the closest thing I can find is defaultacl but the descripion says non-user with no parent. How can I sent the default behavior of a user INBOX sub folder to anyone p If this is what you really want to do (I'm not sure that I'd appreciate the fact that an admin is unilaterally enabling anyone to post to my personal mailboxes), explicitly set 'anyone p' on the INBOX, and this ACL will be inherited by all submailboxes when they are created. Hi all. What is the purpose/usage of p right? I mean, I know what it stands for, post right, giving permission to the user to post a message into that folder. So far, I have been thinking of it in terms of mail delivery, since that is what allows Cyrus to accept messages and file them into a particular folder. Am I right? Yes. So, how come only the owner of a mailbox has p? Does Cyrus switch to the owner, in case of a delivery? INBOXes implicitly have 'p' set to anyone, otherwise most people would never receive their mail. For any other folder, lmtpd checks to see if the authenticated user has the 'p' right. I know I had to give anyone p on shared folders. I tried giving p to user cyrus, but it somehow did not work, not sure why. Delivery is done from Sendmail via LMTP and I did setup auth-info, so Sendmail should have authenticated itself as user cyrus. Is that the right way? The MTA needs to use the AUTH=authid keyword with the MAIL FROM command. It is this authid which is used when checking the ACL. -- Kenneth Murchison Systems Programmer Carnegie Mellon University Cyrus Home Page: http://asg.web.cmu.edu/cyrus Cyrus Wiki/FAQ: http://cyruswiki.andrew.cmu.edu List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: ACLs
Ken Murchison [EMAIL PROTECTED] wrote: I know I had to give anyone p on shared folders. I tried giving p to user cyrus, but it somehow did not work, not sure why. Delivery is done from Sendmail via LMTP and I did setup auth-info, so Sendmail should have authenticated itself as user cyrus. Is that the right way? The MTA needs to use the AUTH=authid keyword with the MAIL FROM command. It is this authid which is used when checking the ACL. Yes yes, but that is the trick! Suppose one's sendmail smtp server has authenticated a sender, and we find that the the message should relay to our Cyrus server, how do we tell Cyrus it was auth'd as that user? We'd welcome reference to any document on the subject. Joseph Brennan Columbia University Information Technology Cyrus Home Page: http://asg.web.cmu.edu/cyrus Cyrus Wiki/FAQ: http://cyruswiki.andrew.cmu.edu List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: ACLs
Joseph Brennan wrote: Ken Murchison [EMAIL PROTECTED] wrote: I know I had to give anyone p on shared folders. I tried giving p to user cyrus, but it somehow did not work, not sure why. Delivery is done from Sendmail via LMTP and I did setup auth-info, so Sendmail should have authenticated itself as user cyrus. Is that the right way? The MTA needs to use the AUTH=authid keyword with the MAIL FROM command. It is this authid which is used when checking the ACL. Yes yes, but that is the trick! Suppose one's sendmail smtp server has authenticated a sender, and we find that the the message should relay to our Cyrus server, how do we tell Cyrus it was auth'd as that user? We'd welcome reference to any document on the subject. I'm not a Sendmail expert, but I believe you must compile Sendmail with -D_FFR_AUTH_PASSING=1 -- Kenneth Murchison Systems Programmer Carnegie Mellon University Cyrus Home Page: http://asg.web.cmu.edu/cyrus Cyrus Wiki/FAQ: http://cyruswiki.andrew.cmu.edu List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: acls on shared folders
wouldn't it let cyrus deliver to shared boxes without having to give anyone p? Am I missing something obvious? Yes, but what is that saving you from? users shooting themselves in the foot. In my experience, users viewing shared folders through an MTA quite often do things they oughtn't: drag messages in, bypassing the distribution list; accidentally delete the folder... Not giving them them permission beyond lrs saves a slew of problems. seph --- Cyrus Home Page: http://asg.web.cmu.edu/cyrus Cyrus Wiki/FAQ: http://cyruswiki.andrew.cmu.edu List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: acls on shared folders
On Sat, 26 Mar 2005, seph wrote: wouldn't it let cyrus deliver to shared boxes without having to give anyone p? Am I missing something obvious? Yes, but what is that saving you from? users shooting themselves in the foot. In my experience, users viewing shared folders through an MTA quite often do things they oughtn't: drag messages in, bypassing the distribution list; accidentally delete the folder... Not giving them them permission beyond lrs saves a slew of problems. Ok, then it makes sense that you want this. --- Cyrus Home Page: http://asg.web.cmu.edu/cyrus Cyrus Wiki/FAQ: http://cyruswiki.andrew.cmu.edu List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: acls on shared folders
On Fri, 25 Mar 2005, seph wrote: I'd like to use a couple shared imap folders to archive some of our internal lists. I can't figure out how to make the acl do what I want. Is there any way to avoid giving anyone the post right? This seems to have come up countless times before, and I haven't ever seen a conclusive answer. My lmtpd logs that it's pre-auth'ed, but I can't figure out how to grant it rights. I found this patch http://asg.web.cmu.edu/archive/message.php?mailbox=archive.cyrus-develmsg=745 but it doesn't seem to have been applied to the current release. Is there some reason that approach is wrong? Well, it hardcodes postman in yet another place but that's about the only complaint. But what does doing this buy you? --- Cyrus Home Page: http://asg.web.cmu.edu/cyrus Cyrus Wiki/FAQ: http://cyruswiki.andrew.cmu.edu List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: acls on shared folders
This seems to have come up countless times before, and I haven't ever seen a conclusive answer. My lmtpd logs that it's pre-auth'ed, but I can't figure out how to grant it rights. I found this patch http://asg.web.cmu.edu/archive/message.php?mailbox=archive.cyrus-develmsg=745 Well, it hardcodes postman in yet another place but that's about the only complaint. But what does doing this buy you? wouldn't it let cyrus deliver to shared boxes without having to give anyone p? Am I missing something obvious? seph --- Cyrus Home Page: http://asg.web.cmu.edu/cyrus Cyrus Wiki/FAQ: http://cyruswiki.andrew.cmu.edu List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: acls on shared folders
On Fri, 25 Mar 2005, seph wrote: Well, it hardcodes postman in yet another place but that's about the only complaint. But what does doing this buy you? wouldn't it let cyrus deliver to shared boxes without having to give anyone p? Am I missing something obvious? Yes, but what is that saving you from? --- Cyrus Home Page: http://asg.web.cmu.edu/cyrus Cyrus Wiki/FAQ: http://cyruswiki.andrew.cmu.edu List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: ACLs, public folders, group:, saslauthd, LDAP, etc.
Howdy, again, Another problem, another email. This problem I've yet to solve. I've got series of mailboxes (straycat.*) and I want to use the group: mechanism to set the ACLs for these mailboxes, as this seems the most elegant solution. I thought to myself, I'll just add all the users to a POSIX group, do a quick 'sam straycat.* group:straycats lrsip', and it'll be all good. Not so. I'm storing all system configuration information (or as much as I can) in LDAP, and I'm using nss_ldap. Authentication is through saslauthd against Kerberos. In fact, here's my imapd.conf: configdirectory: /var/lib/imap partition-default: /var/spool/imap admins: cyrus sievedir: /var/lib/imap/sieve sendmail: /usr/sbin/sendmail hashimapspool: true sasl_keytab: /etc/mail/cyrus-imapd.keytab sasl_pwcheck_method: saslauthd sasl_mech_list: LOGIN PLAIN tls_cert_file: /usr/share/ssl/certs/cyrus-imapd.pem tls_key_file: /usr/share/ssl/certs/cyrus-imapd.pem unix_group_enable: true Pretty simple. Anyways, I've got the group added to LDAP, and 'id user' is showing that getgrent(3) sees the 'straycats' group. However, setting the 'group:straycats' Hi, How is your saslauthd configured? Does 'getent group' show your groups? Simon ACL seems to have only one effect... I now get a ton of the following in /var/log/auth: Feb 20 02:25:05 germ imap[7298]: could not find auxprop plugin, was searching for '[all]' Any help? Thanks. Derek [ derek p. moore ]---[ http://hackunix.org/~derekm/pubkey.asc ] [ [EMAIL PROTECTED] ][ bfd2 fad6 1014 80c9 aaa8 ] [ http://hackunix.org/~derekm/ ]---[ a4a0 f449 3461 a443 51b9 ] This message was sent using IMP, the Internet Messaging Program. --- Home Page: http://asg.web.cmu.edu/cyrus Wiki/FAQ: http://cyruswiki.andrew.cmu.edu List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html --- Home Page: http://asg.web.cmu.edu/cyrus Wiki/FAQ: http://cyruswiki.andrew.cmu.edu List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: ACLs, public folders, group:, saslauthd, LDAP, etc.
Quoting Simon Matter [EMAIL PROTECTED]: Anyways, I've got the group added to LDAP, and 'id user' is showing that getgrent(3) sees the 'straycats' group. However, setting the 'group:straycats' How is your saslauthd configured? I'm using Fedora Raw Hide, so in /etc/sysconfig/saslauthd is export MECH='kerberos5'. In other words, the saslauthd initscript ends up running: /usr/sbin/saslauthd -m /var/run/saslauthd -a kerberos5 Does 'getent group' show your groups? Yes, all of them, including the 'straycats' group I'm trying to use in the ACL. 'getent group straycats' returns: straycats:x:110:derekm,jeff,eric,leon,dafe,ed,kyle,tara,steven I'm stumped, Derek [ derek p. moore ]---[ http://hackunix.org/~derekm/pubkey.asc ] [ [EMAIL PROTECTED] ][ bfd2 fad6 1014 80c9 aaa8 ] [ http://hackunix.org/~derekm/ ]---[ a4a0 f449 3461 a443 51b9 ] This message was sent using IMP, the Internet Messaging Program. --- Home Page: http://asg.web.cmu.edu/cyrus Wiki/FAQ: http://cyruswiki.andrew.cmu.edu List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: ACLs, public folders, group:, saslauthd, LDAP, etc.
Quoting Simon Matter [EMAIL PROTECTED]: Anyways, I've got the group added to LDAP, and 'id user' is showing that getgrent(3) sees the 'straycats' group. However, setting the 'group:straycats' How is your saslauthd configured? I'm using Fedora Raw Hide, so in /etc/sysconfig/saslauthd is export MECH='kerberos5'. In other words, the saslauthd initscript ends up running: /usr/sbin/saslauthd -m /var/run/saslauthd -a kerberos5 Sorry, I have no idea what's wrong here. I did almost the same but with saslauthd against PAM. Could you try pam instead of kerberos just for a test? Simon Does 'getent group' show your groups? Yes, all of them, including the 'straycats' group I'm trying to use in the ACL. 'getent group straycats' returns: straycats:x:110:derekm,jeff,eric,leon,dafe,ed,kyle,tara,steven I'm stumped, Derek [ derek p. moore ]---[ http://hackunix.org/~derekm/pubkey.asc ] [ [EMAIL PROTECTED] ][ bfd2 fad6 1014 80c9 aaa8 ] [ http://hackunix.org/~derekm/ ]---[ a4a0 f449 3461 a443 51b9 ] This message was sent using IMP, the Internet Messaging Program. --- Home Page: http://asg.web.cmu.edu/cyrus Wiki/FAQ: http://cyruswiki.andrew.cmu.edu List Archives/Info: http://asg.web.cmu.edu/cyrus/mailing-list.html
Re: ACLs and such
Hans Wilmer escribió:: BTW, which IMAP clients or other programs are out there that allow users to easily edit their ACLs? A webclient to just set ACLs would also be ok. It would be *very* nice if I could tell our users to set the permissions they want on their mailfolders all on their own :) websieve can manage ACLs as well as sieve scripts. Bye -- Luca Olivetti Wetron Automatización S.A. http://www.wetron.es/ Tel. +34 93 5883004 Fax +34 93 5883007
Re: ACLs and such
On Thu, 6 Feb 2003, Hans Wilmer wrote: BTW, which IMAP clients or other programs are out there that allow users to easily edit their ACLs? A webclient to just set ACLs would also be ok. It would be *very* nice if I could tell our users to set the permissions they want on their mailfolders all on their own :) Mulberry and cyradm both do this (though most people don't immediately jump to the conclusion that cyradm is an IMAP client). -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski * Andrew Systems Group * Cyert Hall 207 * 412-268-7456 Research Systems Programmer * /usr/contributed Gatekeeper
Re: ACLs and such
On Wed, Feb 05, 2003 at 07:47:45PM -0500, Rob Siemborski wrote: So, Offhand, I think the rest of your mail is to special purpose for general use, but I'll address this part of it, since its been brought up before. At least the ability to automatically spread folders across several partitions depending on their names can contribute to performance. Part of the design of cyrus includes the assumption that it's a bigger helpdesk headache when users blow away their own acls (and lose access) than it is if they are actually held bound to them. Therefore, within a user's mailbox hierarchy, you cannot remove full rights for that user. This is a very good point, though it took me some time to understand it. I didn't realize that I cannot remove the 'a' flag from ACLs of user.* mailboxes for their owners. But I can still achieve what I want by creating an 'archives' hierarchy outside the 'user' hierarchy. With permissions set correctly, it's at least even more clear to the users what the archives-stuff is about. BTW, which IMAP clients or other programs are out there that allow users to easily edit their ACLs? A webclient to just set ACLs would also be ok. It would be *very* nice if I could tell our users to set the permissions they want on their mailfolders all on their own :) There are various arguments against this, and I think the final decision was that we look at an implicit rights patch, whereby admins could specify what rights their users had on their mailboxes implicitly (and I seem to remember Ken even made one), but I can't locate it right now. Ken? So this provides control over what rights are inherited? Sounds good :) GH
Re: ACLs and such
On Wed, 5 Feb 2003, Hans Wilmer wrote: cm user.test cm user.test.archives otherpartition sq user.test 100 sq user.test.archives 1000 sam user.test.archives test lrswipca ... and nevertheless allow user 'test' to delete mails and folders residing under user.test.archives by default? The point is that the user must not be able to delete his 'archives' folder, but he must be able to freely operate on anything that resides within that folder. So, Offhand, I think the rest of your mail is to special purpose for general use, but I'll address this part of it, since its been brought up before. Part of the design of cyrus includes the assumption that it's a bigger helpdesk headache when users blow away their own acls (and lose access) than it is if they are actually held bound to them. Therefore, within a user's mailbox hierarchy, you cannot remove full rights for that user. There are various arguments against this, and I think the final decision was that we look at an implicit rights patch, whereby admins could specify what rights their users had on their mailboxes implicitly (and I seem to remember Ken even made one), but I can't locate it right now. Ken? -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski * Andrew Systems Group * Cyert Hall 207 * 412-268-7456 Research Systems Programmer * /usr/contributed Gatekeeper
Re: ACLs and such
Rob Siemborski wrote: On Wed, 5 Feb 2003, Hans Wilmer wrote: cm user.test cm user.test.archives otherpartition sq user.test 100 sq user.test.archives 1000 sam user.test.archives test lrswipca ... and nevertheless allow user 'test' to delete mails and folders residing under user.test.archives by default? The point is that the user must not be able to delete his 'archives' folder, but he must be able to freely operate on anything that resides within that folder. So, Offhand, I think the rest of your mail is to special purpose for general use, but I'll address this part of it, since its been brought up before. Part of the design of cyrus includes the assumption that it's a bigger helpdesk headache when users blow away their own acls (and lose access) than it is if they are actually held bound to them. Therefore, within a user's mailbox hierarchy, you cannot remove full rights for that user. There are various arguments against this, and I think the final decision was that we look at an implicit rights patch, whereby admins could specify what rights their users had on their mailboxes implicitly (and I seem to remember Ken even made one), but I can't locate it right now. Ken? Its in the 2.2 branch. Its probably possible to backport it, but IIRC we discussed this and decided that 2.1 was in feature freeze. -- Kenneth Murchison Oceana Matrix Ltd. Software Engineer 21 Princeton Place 716-662-8973 x26 Orchard Park, NY 14127 --PGP Public Key--http://www.oceana.com/~ken/ksm.pgp
Re: ACLs and such
On Wed, 5 Feb 2003, Ken Murchison wrote: Its in the 2.2 branch. Its probably possible to backport it, but IIRC we discussed this and decided that 2.1 was in feature freeze. Yeah, that makes sense. Need to go get my memory checked ;) -Rob -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Rob Siemborski * Andrew Systems Group * Cyert Hall 207 * 412-268-7456 Research Systems Programmer * /usr/contributed Gatekeeper
