Hi all, thank you all for this long discussion. Your security concerns are clear, as is clearer the intended system-usage scenario (most of you have) and Mutt's role in there.
The difference between us is basically that I prefer that the user have the *possibility* to do it in the "wrong" way after being warned about consequences. Of course sane/secure defaults are a must. Your code, your rules - and thats all right. Best regards, Martin Sacha On 20200813 1807, Derek Martin wrote: > On Thu, Aug 13, 2020 at 10:03:43PM +0200, Vincent Lefevre wrote: > > On 2020-08-11 22:29:41 -0500, Derek Martin wrote: > > > The subversion example is a special case of an application that you > > > use through a web server, that has its own security implications. > > > > Wrong! Subversion does not need a web server. > > I didn't say it was required, and it makes absolutely zero difference: > in your use case you're using your second user to run svnserve--a > network service--which is functionally equivalent to the webserver for > this use case. This is standard security practice for a running > service. You're not supposed to USE that user, and that's actually > the point of having the separate user... If you are you may as well > have just used your normal user, because you're missing the point. > > Then, when you do your checkout, the files will be owned by and > accessible to your main user, not the second user that svnserve is > running as. There is absolutely no cause for the files to be > group-accessible. It's absolutely nothing like your silly contrived > attachment-sharing use case. > > In fact the second user is not yours at all... it belongs to the > subversion repository/service, much as the www-data user belongs to > the web server... not YOU. You can see this more clearly if you > imagine a second human added to your system who will also access the > same repository using the same mechanism and user, and a separate > sysadmin who set this all up for you. And I don't care if that's not > how you'd do it--you COULD, and it illustrates the point. > > And TBH even the svnserve case is a bit silly (over-paranoid), it > provides very little (but yes, some) extra protection. You'd do just > about as well if you never run unstable SVN code and never interact > with your repository any way other than by using svn commands. A > fairly easy way to avoid trashing it accidentally with something like > rm -rf is to put the repository in a very different path from your > home directory or other file store you commonly use, where you have no > reason to be running shell commands. > > > > It's nothing like using multiple users on your system to do different > > > tasks, like reading your e-mail with one user, and then handling > > > attachments with a different one. > > > > Correction: reading e-mail and handling attachments with one uid, > > but also being able to access saved attachments with another uid. > > It's not a correction, those things are equivalent. It's still > superfluous because having multiple users that you're USING is just > idiotic. Switching between users to get things done is going to get in > your way a lot more often than just group perms on e-mail attachments, > so if you want a configurable umask in Mutt because you're running > with this insane use case, for the diminutive boost of efficiency > gained by not having to run chmod on the attchments you actually want > to share, then you've missed the forest for the trees. > > That's why absolutely no one actually does this, without also being > completely insane... or at least completely misunderstanding what > they're doing and why. > > > Note: Even without a sandbox, one does not absolutely need to make > > attachments group accessible. The main account could do a SSHFS mount > > of the directory that contains the saved attachments. But allowing > > to control the permissions of the attachments inside Mutt would avoid > > the need for SSHFS. > > Or just use chmod. Or write a script with a one-character name that > you can run any time you want, to chmod all the files in your > attachments directory, *once you've determined the attachments in a > hard-coded directory have nothing sensitive in them*, if chmod is so > troublesome for you. Or...stop being insane enough to have a use case > that's so contrived and completely ridiculous. > > [I also really want to know who is sending/receiving all these copious > amounts of file attachments that occasionally running chmod on the > ones you actually want to share with someone on the same system is > such a bother...] > > Bottom line: Sharing potentially sensitive data that came to your > inbox should ALWAYS be a forced choice, so that you don't accidentally > make your banking info or medical history etc. available to everyone > on your system, or your raise and bonus info that your boss just > e-mailed you gets shared with your coworkers (or whatever). It should > NEVER be the default, and you're just plain wrong if you think it > should be, even by your own choice. If there's no one else on your > system, and you're not doing something completely idiotic, then it's > entirely a non-issue; and if there are other users on your system, you > DO NOT WANT THIS, even if you think you do. You can do it and it will > be totally fine... right up until that one time it isn't, at which > point you'll finally understand this. Michael did, which is why he > wrote it that way. Thomas did, which is why he adamantly and > explicitly protected Michael's decision (when at the time, I myself > did not), and so did Brendan. And thus far, so too has Kevin. > > I'm done with this thread. You're just wrong, and I think you know > it. > > -- > Derek D. Martin http://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. >
signature.asc
Description: PGP signature
