On 20/02/16 02:05, Sebastian Nielsen wrote: > Everytime I need multiple processes to access the very same file and those > processes has interlocks that prevent them from running as the same user or > same group, I just "fix" the problem with 666. > > That is a thing I ONLY do if I get a permission error when trying to do > something I want to do with some software. So for example, when I want to > edit something from my admin panel on http://www.sebbe.eu , I just 666 that > file to be able to access it from the admin panel. > > Same, I needed to get arp working so HTTP could execute arp for detecting > which MAC addresses users of a captive portal had. I simply 777'd arp > command, because not even 755 worked for some reason, the arp command > required whoever that had execute permission to also have write permission. Apologies for butting in on this discussion. The above reasoning seems to me deeply flawed and something I was guilty of as a Linux newbie back in the late 90s. It is a tempting easy way out.
Rather than addressing the cause of a problem, you are attacking the symptoms and in the process creating unnecessary vulnerabilities in the system. At least that is how I read your brief description. The problem with this, to my mind, is that it introduces sloppyness and this can influence future actions and sub-par "solutions" permanenting potentially harmful workarounds. On my own home gaming box, it's one thing, on a company or client server on the other hand ... /Martin S > > Yeah, I agree that actually, only 644 is required on that config file. But > why get so angry when someone 666's a file to just get things working? > Its not like a list of banned spam domains is something super-sensitive. > > > -----Ursprungligt meddelande----- > Från: Jim Reid [mailto:j...@rfc1035.com] > Skickat: den 20 februari 2016 01:40 > Till: Sebastian Nielsen <sebast...@sebbe.eu> > Kopia: postfix-users@postfix.org > Ämne: access permissions 101 > > >> On 19 Feb 2016, at 23:52, Sebastian Nielsen <sebast...@sebbe.eu> wrote: >> >> but if you're hosting for example a mail server for a company, and only you >> as a sysadmin has shell access to the server, its no danger 666'ing files >> that throw permission errors. Then the file isn't really "world writable", >> since only you have a account on the server anyways. > This is a remarkably stupid and utterly irresponsible thing to say. It’s also > wrong. Very, very wrong. > > One of the fundamental principles of security is least privilege. Things get > the minimum permissions/access rights/whatever that are needed for the task > they have to perform. > > So for postfix only some postfix processes need to have write access from > time to time to specific files and directories. Almost nothing should ever > need write access to postfix's configuration files, except for maybe postmap > when rebuilding hash tables. So postfix's config files shouldn’t be writable > by anyone, not even the postfix user. > > Your starting assumption is also deeply flawed. A world-writable file can be > written to by anything, not just the UIDs who have shell accounts. There will > be other (or should be) UIDs and GIDs allocated to other services that run on > the box: HTTP, DNS, printing, MySQL, postgres, games, spam filters, man > pages, TeX, FTP, etc, etc. That way if one of these things has a security > leak, it can only write to that UID’s writable files (if there are any). The > breakage can’t contaminate anything else. But if someone is stupid enough to > intentionally make config files world-writable, these can be damaged by a > security problem in a rogue application. This is why the TeX user (say) > doesn’t get write access to the DNS or mail or MySQl or.... configuration. > That UID doesn’t need those privileges. So it doesn’t get them. At least, not > on any sensibly managed computer system. > > The logical extension of your approach is to make the password file, kernel, > shared library, etc world-writable. After all, you’re the only one who has > shell access. And you never, ever make mistakes and no software > vulnerabilities of any sort ever occur on the servers you manage - right? > > If you were hosting mail for my business and I found out you’d *deliberately* > set 666 permissions on the mail configuration files my company depended on, > I’d sue you for gross negligence. And win. > > > -- This address is for technical mail lists only.For all other matters, please use my main addressat the .org domain.
