Re: saving messages to files/permissions?
On 25.06.15 11:48, David Champion wrote: There are use cases for allowing specific roles/service accounts access to your unvetted email attachment files. (I would expect these generally have to do with file sharing/export.) Conventionally the only way around this is to proactively degrade your data security and allow world (or group) access. If the attachment is written with unprivileged permissions, then it can hardly be a greater security threat than any other harmless file a user might write. I.e. If the OP were to create attachment files with his ownership, no execute permissions, and some group to which he belongs, then where's the risk? There is no implicit problem with allowing group access. It exists to be used, and serves well to provide broader access _without_ unnecessarily compromising security. If group access is granted, then it is because group access is required. It cannot then be a degradation of security. (I have used it for years on source code repositories to securely determine who had access to what parts of the code base.) To provide group access, without faffing with mutt - and more conveniently allow for multiple groups for the purpose, it is probably most convenient to simply set the sgid bit on the destination directory for a category of attachments, since When SGID is set on a directory, newly created files will inherit the gid of the directory , not that of the user creating the file. To wit: # mkdir /tmp/test # chgrp mail /tmp/test # May have privilege. Make your own. # chmod g+s,o+w /tmp/test # ls -ld /tmp/test drwxr-srwx 2 root mail 1024 Jun 26 17:33 /tmp/test $ touch /tmp/test/fred $ ls -l /tmp/test/fred -rw-r--r-- 1 erik mail 0 Jun 26 17:33 /tmp/test/fred With both the directory and each attachment now having the desired group permissions, they are accessible to all members of that group. Another directory might publish to another crowd. That is the purpose of group permission in *nix, and it serves as well here as it has done in the past. That much, at least, is pretty simple. Is there a case for the OP needing more? Erik -- (5) It is always possible to agglutinate multiple separate problems into a single complex interdependent solution. In most cases this is a bad idea. RFC-1925
Re: saving messages to files/permissions?
On Fri, Jun 26, 2015 at 06:06:50PM +1000, Erik Christiansen wrote: On 25.06.15 11:48, David Champion wrote: There are use cases for allowing specific roles/service accounts access to your unvetted email attachment files. (I would expect these generally have to do with file sharing/export.) Conventionally the only way around this is to proactively degrade your data security and allow world (or group) access. If the attachment is written with unprivileged permissions, then it can hardly be a greater security threat than any other harmless file a user might write. I.e. If the OP were to create attachment files with his ownership, no execute permissions, and some group to which he belongs, then where's the risk? In the case of a role account, it's probably fine... probably. Assuming no one ever misuses the role account and sends things meant to be private to it (which I can almost guarantee you WILL happen, at some point). Otherwise... Suppose you are a team leader, working for Evil Corp. You receive an e-mail from your boss with an attached document detailing how Evil Corp plans to kill a number of its employees due to the discovery that they have been engaged in espionage against the company. You, as their team leader, have been tasked with eliminating a couple of your team members. That's an attachment you definitely don't want your team seeing! Obviously, this is an extreme and contrived example, but suppose instead you are working at an intelligence agency, or a government contractor, a start-up with a new idea, or any company engaged in market-breaking research, etc.. Those organizations are built on secrets to at least some extent, and controlling who has access to them is critical to their success. For someone with the requisite knowledge and access, it's actually fairly simple to create a program to watch the team lead's attachment directory, and steal the contents... the files need only be readable for however long it takes the system to copy them. It exists to be used, and serves well to provide broader access _without_ unnecessarily compromising security. If group access is granted, then it is because group access is required. It cannot then be a degradation of security. Many, many compromises have resulted from the fact that you are simply wrong. :) Most often security is compromised because the thing being protected is misclassified, or the people under its protection are annoyed by the inconvenience and do not understand the consequences, and so circumvent the proscribed protections. You should have seen the look on my former CEO's face when, shortly after my coworker and I were hired, we told him we could mount his mail spool on any desktop in the company... I am not making this up! (I have used it for years on source code repositories to securely determine who had access to what parts of the code base.) Sure, that's a great use for group permissions. But that hardly means that group should have access to absolutely everything that you do... or every attachment you save, even briefly. drwxr-srwx 2 root mail 1024 Jun 26 17:33 /tmp/test $ touch /tmp/test/fred $ ls -l /tmp/test/fred -rw-r--r-- 1 erik mail 0 Jun 26 17:33 /tmp/test/fred [...] That much, at least, is pretty simple. Is there a case for the OP needing more? What you're missing is that Mutt explicitly opens the files for the attachments it creates with 0600 permissions. So while you're right that this will set the GID of the files that are saved there, the group will still not be able to access them until the owner uses chmod on them. Which is a Good Thing™. -=-=-=-=- Incidentally, it's often not understood that group perms can be used to take away access... For instance, say the file you just created had these permissions: -rwr-- 1 erik mail 0 Jun 26 17:33 /tmp/test/fred In other words, world-readable but the group mail has no access. In that case, anyone in group mail will NOT be able to read that file, with the exception of erik. Permissions are checked in heirarchical order, i.e. user (owner), group, and then other. The permissions applied to a particular user are those from the first class that match the user's credentials. -- Derek D. Martinhttp://www.pizzashack.org/ GPG Key ID: 0xDFBEAD02 -=-=-=-=- This message is posted from an invalid address. Replying to it will result in undeliverable mail due to spam prevention. Sorry for the inconvenience. pgpBslm0uCbog.pgp Description: PGP signature
Re: saving messages to files/permissions?
On 26.06.15 18:06, Erik Christiansen wrote: # chmod g+s,o+w /tmp/test Allowing other to publish to the group was done for the purpose of a quick confirmation that sgid does what we expect. In practice, it would be more secure for the publisher to own the directory, and only set the sgid bit. Erik
Re: saving messages to files/permissions?
On Thu, Jun 25, 2015 at 01:25:19PM -0500, Derek Martin wrote: On Thu, Jun 25, 2015 at 11:48:57AM -0500, David Champion wrote: I generally agree with Derek but I want to point out one exception to this. There are use cases for allowing specific roles/service accounts access to your unvetted email attachment files. My argument here is that these things should not exist and should be effectively replaced by mailing lists and header editing, or something similar--but I understand that some people who need this type of functionality have poor options for doing those things, so I will not complain too loudly. :) On the other hand, those without options are probably not running mutt! =8^) -- Derek D. Martinhttp://www.pizzashack.org/ GPG Key ID: 0xDFBEAD02 -=-=-=-=- This message is posted from an invalid address. Replying to it will result in undeliverable mail due to spam prevention. Sorry for the inconvenience. pgpHiciYp8KDL.pgp Description: PGP signature
Re: saving messages to files/permissions?
On Thu, Jun 25, 2015 at 11:48:57AM -0500, David Champion wrote: * On 25 Jun 2015, Derek Martin wrote: to secure it. That is a massive security failure. If other people are on your system and have access to the directory where your attachments are stored, YOU DO NOT WANT THIS. And if not, YOU DO NOT NEED THIS. So practically speaking there's no good, and significant I generally agree with Derek but I want to point out one exception to this. There are use cases for allowing specific roles/service accounts access to your unvetted email attachment files. My argument here is that these things should not exist and should be effectively replaced by mailing lists and header editing, or something similar--but I understand that some people who need this type of functionality have poor options for doing those things, so I will not complain too loudly. :) -- Derek D. Martinhttp://www.pizzashack.org/ GPG Key ID: 0xDFBEAD02 -=-=-=-=- This message is posted from an invalid address. Replying to it will result in undeliverable mail due to spam prevention. Sorry for the inconvenience. pgpQgJXMbOayK.pgp Description: PGP signature
Re: saving messages to files/permissions?
On 17Jun15 12:37 -0500, Derek Martin wrote: On Sun, Jun 14, 2015 at 09:36:44PM +0200, bastian-muttu...@t6l.de wrote: On 13Jun15 22:55 -0700, Ian Zimmerman wrote: I think it is worth to solve the trouble of file permissions. FMPOV this behaviour is not typical to unix philosophy, because you cannot influence file modes via the umask syscall. This is wrong. The file permissions are what they are quite specifically and intentionally for security reasons. If you want to make the files less secure, you are required to make a conscious decision on a case-by-case basis, and take action to do so, and that is as it should be. Right, I want to make files less secure and I really know a lot about the implications. The point where I see room for improvement is the lack of configurability to be able to change the behaviour of writing out attachment files - not mailbox files. Everything tends to be configurable in mutt. Whereas, hard-coding umask and file mode bits does not look like the ultimate mutt-like solution FMPOV. This issue has been discussed and debated ad nauseum in the past, and this is one of those cases where the developers should do (and have done) what is right without regard to what the users want, because what the users want is simply just plain wrong--but they've proven too difficult to be convinced of that. I'm not going to rehash the argument here; if you search the archives, you should find the discussion. Whether anyone likes it or not, the fact is that when it comes to software security, most users--and even a large portion of the developers--just don't have any idea what they are talking about, and to some extent people who know better need to make the decision for them to prevent the possibility of bad things happening on a wide-spread basis. This is one of those cases--the small inconvenience of having to manually change the permissions is VASTLY outweighed by the harm that could be done by allowing for the file permissions to be less restrictive by default. I can still survive while doing that. But I have to admit, I do not get the clue, why I should want my attachment files to be handled in an imposed and uninfluenceable 'top-secret' manner. All other files I work with in the same 'classification level' are created with the umask setting I chose in .profile. However, it would be good to document this somewhere, since it's come up more than once. Cheers, -- Bastian
Re: Quotes [Was: saving messages to files/permissions?]
On Sun, Jun 21, 2015 at 06:41:05PM +1000, Erik Christiansen wrote: On 20.06.15 15:18, Will Yardley wrote: On Sat, Jun 20, 2015 at 08:25:39PM +1000, Erik Christiansen wrote: ISTM that you're painting it more complex than the reality. It is easier than the above with the original simpler presentation, where each attribution begins at the top of its own '' column. There is then no more effort than following a straight vertical line directly to the author. Yes, but most people don't use SuperCite, Errr, Will, _I_ don't use SuperCite. The simplicity I've attempted to explain _is_ the default traditional quoting. The above text is just mutt's implementation of the de facto standard. One squint is enough to check who wrote what, 'cos it all just lines up. Right, I know that. I thought you were talking about [someone else's] somewhat flip example of: Joe Harry Jane Joe Harry Joe vs. Joe Harry Jane pointing out that they're only one level deep (which is indeed the case if everyone's using SuperCite). w
Re: Quotes [Was: saving messages to files/permissions?]
On 20.06.15 15:18, Will Yardley wrote: On Sat, Jun 20, 2015 at 08:25:39PM +1000, Erik Christiansen wrote: ISTM that you're painting it more complex than the reality. It is easier than the above with the original simpler presentation, where each attribution begins at the top of its own '' column. There is then no more effort than following a straight vertical line directly to the author. Yes, but most people don't use SuperCite, Errr, Will, _I_ don't use SuperCite. The simplicity I've attempted to explain _is_ the default traditional quoting. The above text is just mutt's implementation of the de facto standard. One squint is enough to check who wrote what, 'cos it all just lines up. so once some more people respond to a message, you could end up with a jumble more like: Humpbert blah blah. The quick brown fox jumped over the lazy dog. I Humpbert think that now is the time. Jane I think something else. Some text here etc. etc. I don't know what is used to muck up the de facto standard in that precise manner. Heck, a poster can do it by hand if sufficiently determined. In the wild, you could end up with anything - even flowed text! The case I made, in response to the original attack on the standard, is that the standard works well when correctly used. I find it a peculiarly weak counterargument to demonstrate that failure to follow the standard is less effective than correctly following it. My response is Yes. Thank you for agreeing with those who enjoy the standard. I haven't used it myself, but seems like there are some corner cases that I imagine would also present problems, such as when someone doesn't provide a full name, or when more than one person being quoted has the same name. That occurred to me too, but I was reluctant to add complexity to a case for the simplicity of the de facto standard. Overall, I just think it's rude to use a style of quoting that's non-standard, because once you end up with nested quotes and so on, it can be a giant mess. The conventional way of quoting works fine *if* people trim and attribute correctly. Thank you for agreeing at least 100%. I hadn't gone so far as actively criticising cutting across standard quoting with a contrary method, but I take your point - it is uncooperative. In terms of how quoted material is *rendered* within a MUA, that's a different issue, and especially with format=flowed text that's properly encoded, I could see arguments for making the display view (not the editor view) use, say, solid vertical lines, as some GUI mailers do. Who could disagree? Render it in pink or puce, by all means. Erik (A bit puzzled by apparent loss of synch, somewhere.) -- Only that in you which is me hears what I am saying - Baba Ram Dass
Re: Quotes [Was: saving messages to files/permissions?]
On 19.06.15 17:11, David Champion wrote: Ian Erik Mattias Chris Tom Greetings all, Not sure if this may be a Ian Erik Mattias Chris Tom debian problem but Ian Erik Mattias Chris Tom Ian Erik Mattias Chris Tom I often save individual incomming emails Ian Erik Mattias Chris Tom in seperate files in my home directory Ian Erik Mattias Chris Tom with the mutt s command. Ian Erik Mattias Chris Tom Ian Erik Mattias Chris Tom In any session, the first time I save to Ian Erik Mattias Chris Tom a particular file it goes fine. Ian Erik Mattias Chris Tom Ian Erik Mattias Chris Tom However if I try to save another message Ian Erik Mattias Chris Tom to the same file, I get Permission Ian Erik Mattias Chris Tom denied. Ian Ian Erik Chris I never wrote any of the above! Ian Ian Erik And the quoting does show that. Compare the inner Chris Ian Erik Bannister quote with the outer: In the outer, the leftmost Ian Erik '' ladder links your name with the last quoted sentence. In Ian Erik your inner, the third '' ladder links your name with nothing Ian Erik at all, i.e. no attribution to you. The whole of the central Ian Erik block of quoted text is solidly attributed to Tom Fowle by an Ian Erik unbroken fourth '' ladder, is it not? Ian Ian Now compare this correct, but horribly complex analysis (can a Ian human really do that habitually?) with the SuperCite nonstandard Ian [1] quoting I use. Which is easier to read, honestly? If it is Ian a matter of colorizing in the mutt pager, a simple setting of Ian quote_regexp in .muttrc fixes that. (This should count as ob-mutt Ian content.) Are we really going to do this? ISTM that you're painting it more complex than the reality. It is easier than the above with the original simpler presentation, where each attribution begins at the top of its own '' column. There is then no more effort than following a straight vertical line directly to the author. One squint - gotcha! I'm sorry, but I fail to see how that can be made out to be difficult. (If the font were tall, and '' substituted with '|', then David's text above would be joined to his attribution by a solid line, not just a line of '', but the simplicity is the same. If he hadn't munged the others, then they would be similarly simple vertical lines to follow with a glance.) I do it when reading an email. I do it and double check when trimming quoted text, to ensure that the attribution line for each quoting column not trimmed is still present. It is not an effort that is in any way irksome. What I like very much is that Vim perfectly maintains such quoting when reflowing quoted paragraphs, e.g with gq} - something I do when trimming from or to the middle of a line, or when the lines are too long. (Granted, fullquoters can make the '' columns overly long, but that's the fault of failing to trim quoted text to that relevant to the reply.) Erik -- Habit is habit, and not to be flung out of the window by any man, but coaxed down-stairs a step at a time. - Mark Twain, Pudd'nhead Wilson's Calendar
Re: Quotes [Was: saving messages to files/permissions?]
On Sat, Jun 20, 2015 at 08:25:39PM +1000, Erik Christiansen wrote: On 19.06.15 17:11, David Champion wrote: Are we really going to do this? ISTM that you're painting it more complex than the reality. It is easier than the above with the original simpler presentation, where each attribution begins at the top of its own '' column. There is then no more effort than following a straight vertical line directly to the author. Yes, but most people don't use SuperCite, so once some more people respond to a message, you could end up with a jumble more like: Humpbert blah blah. The quick brown fox jumped over the lazy dog. I Humpbert think that now is the time. Jane I think something else. Some text here etc. etc. I haven't used it myself, but seems like there are some corner cases that I imagine would also present problems, such as when someone doesn't provide a full name, or when more than one person being quoted has the same name. Overall, I just think it's rude to use a style of quoting that's non-standard, because once you end up with nested quotes and so on, it can be a giant mess. The conventional way of quoting works fine *if* people trim and attribute correctly. In terms of how quoted material is *rendered* within a MUA, that's a different issue, and especially with format=flowed text that's properly encoded, I could see arguments for making the display view (not the editor view) use, say, solid vertical lines, as some GUI mailers do. w
Re: Quotes [Was: saving messages to files/permissions?]
Ian Erik Mattias Chris Tom Greetings all, Not sure if this may be a Ian Erik Mattias Chris Tom debian problem but Ian Erik Mattias Chris Tom Ian Erik Mattias Chris Tom I often save individual incomming emails Ian Erik Mattias Chris Tom in seperate files in my home directory Ian Erik Mattias Chris Tom with the mutt s command. Ian Erik Mattias Chris Tom Ian Erik Mattias Chris Tom In any session, the first time I save to Ian Erik Mattias Chris Tom a particular file it goes fine. Ian Erik Mattias Chris Tom Ian Erik Mattias Chris Tom However if I try to save another message Ian Erik Mattias Chris Tom to the same file, I get Permission Ian Erik Mattias Chris Tom denied. Ian Ian Erik Chris I never wrote any of the above! Ian Ian Erik And the quoting does show that. Compare the inner Chris Ian Erik Bannister quote with the outer: In the outer, the leftmost Ian Erik '' ladder links your name with the last quoted sentence. In Ian Erik your inner, the third '' ladder links your name with nothing Ian Erik at all, i.e. no attribution to you. The whole of the central Ian Erik block of quoted text is solidly attributed to Tom Fowle by an Ian Erik unbroken fourth '' ladder, is it not? Ian Ian Now compare this correct, but horribly complex analysis (can a Ian human really do that habitually?) with the SuperCite nonstandard Ian [1] quoting I use. Which is easier to read, honestly? If it is Ian a matter of colorizing in the mutt pager, a simple setting of Ian quote_regexp in .muttrc fixes that. (This should count as ob-mutt Ian content.) Are we really going to do this? -- David Champion • d...@uchicago.edu • University of Chicago
Re: Quotes [Was: saving messages to files/permissions?]
On 2015-06-19 17:11 -0500, David Champion wrote: Ian Now compare this correct, but horribly complex analysis (can a Ian human really do that habitually?) with the SuperCite nonstandard Ian [1] quoting I use. Which is easier to read, honestly? If it is Ian a matter of colorizing in the mutt pager, a simple setting of Ian quote_regexp in .muttrc fixes that. (This should count as ob-mutt Ian content.) David Are we really going to do this? Of course not. ;-) Anyway, I'm fine with using supercite sparingly - only when multiple different attributions are required. Then the readability difference does matter to me. -- Please *no* private copies of mailing list or newsgroup messages. Rule 420: All persons more than eight miles high to leave the court.
Re: Quotes [Was: saving messages to files/permissions?]
On 18.06.15 08:59, Ian Zimmerman wrote: On 2015-06-18 21:06 +1000, Erik Christiansen wrote: Chris I never wrote any of the above! Erik And the quoting does show that. Compare the inner Chris Erik Bannister quote with the outer: In the outer, the leftmost '' Erik ladder links your name with the last quoted sentence. In your Erik inner, the third '' ladder links your name with nothing at all, Erik i.e. no attribution to you. The whole of the central block of Erik quoted text is solidly attributed to Tom Fowle by an unbroken Erik fourth '' ladder, is it not? Now compare this correct, but horribly complex analysis (can a human really do that habitually?) with the SuperCite nonstandard [1] quoting I use. Shooting yourself in the foot is your problem, whether you are adult enough to understand that or not. Your deliberate corruption of the columnar alignment preserved by all the positive contributors to the thread is not something which concerns anyone else. Proper traditional quoting is almost universal on all the mailing lists I inhabit, and I delete unread most posts which deviate, simply because it is not worth my time to bother with nonstandard flowed rubbish. To come the raw prawn with such nonsense on the mutt ML in particular would border on trolling, were it not so comical. Do you post because we are supposed to feel sorry for your masochism? If email is uncomfortable, may I recommend the newfangled twitterface thing? Erik -- Patient: Doctor, it hurts when I do this... Doctor: Well, don't do that!
Re: saving messages to files/permissions?
On 18.06.15 22:14, Chris Bannister wrote: On Mon, Jun 15, 2015 at 11:31:01AM +0200, Matthias Apitz wrote: El día Monday, June 15, 2015 a las 07:43:18AM +1200, Chris Bannister escribió: Huh? On Sat, Jun 13, 2015 at 09:59:40PM -0700, Tom Fowle wrote: Greetings all, Not sure if this may be a debian problem but I often save individual incomming emails in seperate files in my home directory with the mutt s command. In any session, the first time I save to a particular file it goes fine. However if I try to save another message to the same file, I get Permission denied. I never wrote any of the above! And the quoting does show that. Compare the inner Chris Bannister quote with the outer: In the outer, the leftmost '' ladder links your name with the last quoted sentence. In your inner, the third '' ladder links your name with nothing at all, i.e. no attribution to you. The whole of the central block of quoted text is solidly attributed to Tom Fowle by an unbroken fourth '' ladder, is it not? If there's a problem there, then it eludes me. Erik -- ARTHUR: But if he was dying, he wouldn't bother to carve Arrggghhh. He'd just say it. BROTHER MAYNARD: It's down there carved in stone. GALAHAD: Perhaps he was dictating. Monty Python and the Holy Grail PYTHON (MONTY) PICTURES LTD
Re: saving messages to files/permissions?
On Thu, Jun 18, 2015 at 12:25:51PM +0200, Matthias Apitz wrote: El día Thursday, June 18, 2015 a las 10:14:54PM +1200, Chris Bannister escribió: On Mon, Jun 15, 2015 at 11:31:01AM +0200, Matthias Apitz wrote: El día Monday, June 15, 2015 a las 07:43:18AM +1200, Chris Bannister escribió: Huh? On Sat, Jun 13, 2015 at 09:59:40PM -0700, Tom Fowle wrote: Greetings all, Not sure if this may be a debian problem but I often save individual incomming emails in seperate files in my home directory with the mutt s command. In any session, the first time I save to a particular file it goes fine. However if I try to save another message to the same file, I get Permission denied. I never wrote any of the above! Please be careful with your atrributions/snipping. To the OP: Can you please post here: $ ls -ld . $ ls -l file-to-save-in $ id I do not understand, what you mean. I just use one of the mails from the list and wrote below(!) the text starting with To the OP... Ahh, OK. in that case, sorry about that, but seeing my name at the top of the attributions and not seeing any of the text I remember writing in the email prompted my reaction, and is also why I added the 'snipping' proviso. -- If you're not careful, the newspapers will have you hating the people who are being oppressed, and loving the people who are doing the oppressing. --- Malcolm X
Re: Quotes [Was: saving messages to files/permissions?]
On Thu, Jun 18, 2015 at 08:59:53AM -0700, Ian Zimmerman wrote: On 2015-06-18 21:06 +1000, Erik Christiansen wrote: Chris I never wrote any of the above! Now compare this correct, but horribly complex analysis (can a human really do that habitually?) Yes, absolutely, if the quoting and attribution have been done properly. Sadly some (blessedly) few just can't be bothered, though most do get it right. I've been reading e-mail quoted this way for nearly 30 years, and the number of times I've had a problem attributing a quote could, I would estimate, be counted on my fingers. Your non-standard way works but it is indeed nonstandard and as such many mailers choke on it. Mutt is thankfully not one of those. But even still, when there's a lot of this (which is exceedingly rare) it can still get to be a problem, mostly because other people mishandle it (or more accurately, simply DO NOT handle it). Which RFC specifies the multi- quoting, anyway? IIRC, it's in no RFC--it's a DEFACTO standard from almost 50 years of convention. -- Derek D. Martinhttp://www.pizzashack.org/ GPG Key ID: 0xDFBEAD02 -=-=-=-=- This message is posted from an invalid address. Replying to it will result in undeliverable mail due to spam prevention. Sorry for the inconvenience. pgp7AuNS6MqhH.pgp Description: PGP signature
Quotes [Was: saving messages to files/permissions?]
On 2015-06-18 21:06 +1000, Erik Christiansen wrote: Chris I never wrote any of the above! Erik And the quoting does show that. Compare the inner Chris Erik Bannister quote with the outer: In the outer, the leftmost '' Erik ladder links your name with the last quoted sentence. In your Erik inner, the third '' ladder links your name with nothing at all, Erik i.e. no attribution to you. The whole of the central block of Erik quoted text is solidly attributed to Tom Fowle by an unbroken Erik fourth '' ladder, is it not? Now compare this correct, but horribly complex analysis (can a human really do that habitually?) with the SuperCite nonstandard [1] quoting I use. Which is easier to read, honestly? If it is a matter of colorizing in the mutt pager, a simple setting of quote_regexp in .muttrc fixes that. (This should count as ob-mutt content.) [1] Which RFC specifies the multi- quoting, anyway? -- Please *no* private copies of mailing list or newsgroup messages. Rule 420: All persons more than eight miles high to leave the court.
Re: Quotes [Was: saving messages to files/permissions?]
On Thu, Jun 18, 2015 at 12:20:51PM -0500, Derek Martin wrote: On Thu, Jun 18, 2015 at 08:59:53AM -0700, Ian Zimmerman wrote: Which RFC specifies the multi- quoting, anyway? IIRC, it's in no RFC--it's a DEFACTO standard from almost 50 years of convention. Though the RFCs for flowed text (2646, 3676, section 4.5) do specify as the canonical quote marker for format=flowed. https://en.wikipedia.org/wiki/Posting_style mentions: There is no standard declaring one quote-prefix to be right and others to be wrong, but some standards depend on conventional quoting. The (unpublished) son-of-1036 draft recommends as the quote-prefix; the son-of-1036 draft is in rfc1849. https://tools.ietf.org/html/rfc1849 w
Re: saving messages to files/permissions?
On Mon, Jun 15, 2015 at 11:31:01AM +0200, Matthias Apitz wrote: El día Monday, June 15, 2015 a las 07:43:18AM +1200, Chris Bannister escribió: Huh? On Sat, Jun 13, 2015 at 09:59:40PM -0700, Tom Fowle wrote: Greetings all, Not sure if this may be a debian problem but I often save individual incomming emails in seperate files in my home directory with the mutt s command. In any session, the first time I save to a particular file it goes fine. However if I try to save another message to the same file, I get Permission denied. I never wrote any of the above! Please be careful with your atrributions/snipping. To the OP: Can you please post here: $ ls -ld . $ ls -l file-to-save-in $ id -- If you're not careful, the newspapers will have you hating the people who are being oppressed, and loving the people who are doing the oppressing. --- Malcolm X
Re: saving messages to files/permissions?
El día Thursday, June 18, 2015 a las 10:14:54PM +1200, Chris Bannister escribió: On Mon, Jun 15, 2015 at 11:31:01AM +0200, Matthias Apitz wrote: El día Monday, June 15, 2015 a las 07:43:18AM +1200, Chris Bannister escribió: Huh? On Sat, Jun 13, 2015 at 09:59:40PM -0700, Tom Fowle wrote: Greetings all, Not sure if this may be a debian problem but I often save individual incomming emails in seperate files in my home directory with the mutt s command. In any session, the first time I save to a particular file it goes fine. However if I try to save another message to the same file, I get Permission denied. I never wrote any of the above! Please be careful with your atrributions/snipping. To the OP: Can you please post here: $ ls -ld . $ ls -l file-to-save-in $ id I do not understand, what you mean. I just use one of the mails from the list and wrote below(!) the text starting with To the OP... Please check the archive of the list matthias -- Matthias Apitz, g...@unixarea.de, http://www.unixarea.de/ +49-170-4527211 +49-176-38902045 Wenn der Mensch von den Umständen gebildet wird, so muß man die Umstände menschlich bilden. Si el hombre es formado por las circunstancias entonces es necesario formar humanamente las circunstancias, Karl Marx in Die heilige Familie / La sagrada familia (MEW 2, 138)
Re: saving messages to files/permissions?
In-Reply-To: 20150614193616.ga...@tweddell.de 20150614045940.GA3721@localhost.localdomain On Sat, Jun 13, 2015 at 09:59:40PM -0700, Tom Fowle wrote: [reformatted for brevity] I often save individual incomming emails in seperate files in my home directory with the mutt s command. In any session, the first time I save to a particular file it goes fine. However if I try to save another message to the same file, I get Permission denied. checking the permission of the file it is -rw- --- --- As others have said, this should not present you with any problems. If it does happen again, you should really take a look at why--it's most likely you've done something else wrong. The more interesting point is this: On Sun, Jun 14, 2015 at 09:36:44PM +0200, bastian-muttu...@t6l.de wrote: On 13Jun15 22:55 -0700, Ian Zimmerman wrote: I think it is worth to solve the trouble of file permissions. FMPOV this behaviour is not typical to unix philosophy, because you cannot influence file modes via the umask syscall. This is wrong. The file permissions are what they are quite specifically and intentionally for security reasons. If you want to make the files less secure, you are required to make a conscious decision on a case-by-case basis, and take action to do so, and that is as it should be. This issue has been discussed and debated ad nauseum in the past, and this is one of those cases where the developers should do (and have done) what is right without regard to what the users want, because what the users want is simply just plain wrong--but they've proven too difficult to be convinced of that. I'm not going to rehash the argument here; if you search the archives, you should find the discussion. Whether anyone likes it or not, the fact is that when it comes to software security, most users--and even a large portion of the developers--just don't have any idea what they are talking about, and to some extent people who know better need to make the decision for them to prevent the possibility of bad things happening on a wide-spread basis. This is one of those cases--the small inconvenience of having to manually change the permissions is VASTLY outweighed by the harm that could be done by allowing for the file permissions to be less restrictive by default. However, it would be good to document this somewhere, since it's come up more than once. -- Derek D. Martinhttp://www.pizzashack.org/ GPG Key ID: 0xDFBEAD02 -=-=-=-=- This message is posted from an invalid address. Replying to it will result in undeliverable mail due to spam prevention. Sorry for the inconvenience. pgpQgJmhkDKLt.pgp Description: PGP signature
Re: saving messages to files/permissions?
On 15Jun15 11:31 +0200, Matthias Apitz wrote: To the OP: Can you please post here: $ ls -ld . $ ls -l file-to-save-in $ id In addition: df -T . mutt -v Cheers, -- Bastian
Re: saving messages to files/permissions?
On Sat, Jun 13, 2015 at 09:59:40PM -0700, Tom Fowle wrote: Greetings all, Not sure if this may be a debian problem but I often save individual incomming emails in seperate files in my home directory with the mutt s command. In any session, the first time I save to a particular file it goes fine. However if I try to save another message to the same file, I get Permission denied. I run Debian, and I don't have that problem so I can validate that it is not a Debian problem. -- If you're not careful, the newspapers will have you hating the people who are being oppressed, and loving the people who are doing the oppressing. --- Malcolm X
Re: saving messages to files/permissions?
All, the problem has resolved its self If it occurrs again, I will follow these requests. Thanks and sorry for the non-repeatable non-issue? Tom On Mon, Jun 15, 2015 at 12:59:17PM +0200, bastian-muttu...@t6l.de wrote: On 15Jun15 11:31 +0200, Matthias Apitz wrote: To the OP: Can you please post here: $ ls -ld . $ ls -l file-to-save-in $ id In addition: df -T . mutt -v Cheers, -- Bastian
Re: saving messages to files/permissions?
On 2015-06-13 21:59 -0700, Tom Fowle wrote: Tom I often save individual incomming emails in seperate files in my Tom home directory with the mutt s command. In any session, the Tom first time I save to a particular file it goes fine. However if I Tom try to save another message to the same file, I get Permission Tom denied. Tom checking the permission of the file it is -rw- --- --- Tom I can, of course open another console and chmod to correct this Tom without leaving mutt, but I don't recall this problem with my Tom previously installed old fedora. Wait, something is odd here. Are you running mutt as a different user? If not, why would it have any trouble writing to a file with 0600 permissions? Those two bits are _user_ read and write, after all. I think you should attack this angle before you try to change the permissions. strace may be your friend. -- Please *no* private copies of mailing list or newsgroup messages. Rule 420: All persons more than eight miles high to leave the court.
Re: saving messages to files/permissions?
On Sat, Jun 13, 2015 at 09:59:40PM -0700, Tom Fowle wrote: Greetings all, Not sure if this may be a debian problem but I often save individual incomming emails in seperate files in my home directory with the mutt s command. In any session, the first time I save to a particular file it goes fine. However if I try to save another message to the same file, I get Permission denied. checking the permission of the file it is -rw- --- --- I can, of course open another console and chmod to correct this without leaving mutt, but I don't recall this problem with my previously installed old fedora. It appears the default debian umask should be 622 not 600, but getumask gets command not found. I second Ian's comments regarding check ownership and mutt user problems first. But if you do look at umask two points. I know of no getumask, but the umask command itself will report the current setting. Umask is the modes you do NOT want set on new files. So the umask that created -rw--- is 066 (for ordinary files 077 would work too but directory creation would be different). -- Jon H. LaBadie j...@jgcomp.com 11226 South Shore Rd. (703) 787-0688 (H) Reston, VA 20190 (703) 935-6720 (C)
Your hostname [Was: saving messages to files/permissions?]
BTW, you should configure your system so that mutt puts some sensible domain in your message-id, instead of localhost.localdomain. I think on debian the file /etc/mailname is the one to change. -- Please *no* private copies of mailing list or newsgroup messages. Rule 420: All persons more than eight miles high to leave the court.
Re: saving messages to files/permissions?
As so often happens, having changed nothing I know of, I can now save messages to a file just fine Have no idea what happened Who ever said computers are consistant! Re: localhost.localdomain I know the host name, but not sure which domain name to usewill keep looking Appologies for misdirected and duplicate replies to list and individuals, had forgotten the L command is proper for this list. Other lists it doesn't work Thanks and sorry for the chaos. Maybe my domain name is chaos.duh tom fowle On Sun, Jun 14, 2015 at 03:14:06AM -0400, Jon LaBadie wrote: On Sat, Jun 13, 2015 at 09:59:40PM -0700, Tom Fowle wrote: Greetings all, Not sure if this may be a debian problem but I often save individual incomming emails in seperate files in my home directory with the mutt s command. In any session, the first time I save to a particular file it goes fine. However if I try to save another message to the same file, I get Permission denied. checking the permission of the file it is -rw- --- --- I can, of course open another console and chmod to correct this without leaving mutt, but I don't recall this problem with my previously installed old fedora. It appears the default debian umask should be 622 not 600, but getumask gets command not found. I second Ian's comments regarding check ownership and mutt user problems first. But if you do look at umask two points. I know of no getumask, but the umask command itself will report the current setting. Umask is the modes you do NOT want set on new files. So the umask that created -rw--- is 066 (for ordinary files 077 would work too but directory creation would be different). -- Jon H. LaBadie j...@jgcomp.com 11226 South Shore Rd. (703) 787-0688 (H) Reston, VA 20190 (703) 935-6720 (C)
Re: saving messages to files/permissions?
On 13Jun15 22:55 -0700, Ian Zimmerman wrote: On 2015-06-13 21:59 -0700, Tom Fowle wrote: Tom I often save individual incomming emails in seperate files in my Tom home directory with the mutt s command. In any session, the Tom first time I save to a particular file it goes fine. However if I Tom try to save another message to the same file, I get Permission Tom denied. Tom checking the permission of the file it is -rw- --- --- Tom I can, of course open another console and chmod to correct this Tom without leaving mutt, but I don't recall this problem with my Tom previously installed old fedora. Wait, something is odd here. Are you running mutt as a different user? If not, why would it have any trouble writing to a file with 0600 permissions? Those two bits are _user_ read and write, after all. I think you should attack this angle before you try to change the permissions. I think it is worth to solve the trouble of file permissions. FMPOV this behaviour is not typical to unix philosophy, because you cannot influence file modes via the umask syscall. This behaviour also bothered me, even though I use just one UID basically. See below for my reasons to work on it, if interested. strace may be your friend. Code rules. In my current mutt (Mutt 1.5.23+89 (0255b37be491) (2014-03-12)) I find two locations, where umask and mode bits are set hard-coded, so no way to modify without re-compiling. First, main.c:599 umask (077); This could be set to 022, which also opens other permissions to other users. So you should know if you really want it. Second, lib.c:645 and :657 if ((fd = open (safe_file, flags, 0600)) 0) Here again, when files are opened in a safe way when writing out attachements, file mode bits are set hard-coded :/ Here you can set 0666 as mode bits. The open syscall also binary-ands () the bits from the umask setting, either set them globally to 022 in main.c or - the way I'd propose - change umask before writing out attachements and then reset to the previous one. Finally, here is my trouble with it. I got used to save attachments to ~/public_html/$somewhere to have them available remotely via browser. I always had to chmod a+r manually to enable all users including the web server process to read that files. In addition, these hard-coded umask and file mode bit settings are in the mutt source repositories (see version reference above), so I think the same behaviour should be seen on fedora, but I don't about any patches from their side. Cheers, -- Bastian
saving messages to files/permissions?
Greetings all, Not sure if this may be a debian problem but I often save individual incomming emails in seperate files in my home directory with the mutt s command. In any session, the first time I save to a particular file it goes fine. However if I try to save another message to the same file, I get Permission denied. checking the permission of the file it is -rw- --- --- I can, of course open another console and chmod to correct this without leaving mutt, but I don't recall this problem with my previously installed old fedora. It appears the default debian umask should be 622 not 600, but getumask gets command not found. Is this both a debian and a mutt issue? Is there a nice neat solution? thanks, and sorry if off topic Tom Fowle
