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
