Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1031583AbbKDS2f (ORCPT ); Wed, 4 Nov 2015 13:28:35 -0500 Received: from wtarreau.pck.nerim.net ([62.212.114.60]:46554 "EHLO 1wt.eu" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1031527AbbKDS2Y (ORCPT ); Wed, 4 Nov 2015 13:28:24 -0500 Date: Wed, 4 Nov 2015 19:28:13 +0100 From: Willy Tarreau To: Andy Lutomirski Cc: Kees Cook , Dirk Steinmetz , Michael Kerrisk-manpages , Serge Hallyn , Seth Forshee , Alexander Viro , Linux FS Devel , LKML , "Eric W . Biederman" , Serge Hallyn , "security@kernel.org" Subject: Re: [RFC] namei: prevent sgid-hardlinks for unmapped gids Message-ID: <20151104182813.GE22318@1wt.eu> References: <1446511187-9131-1-git-send-email-public@rsjtdrjgfuzkfg.com> <20151104002132.010ccd1d@rsjtdrjgfuzkfg.com> <20151104065820.GF21740@1wt.eu> <20151104181519.GC22318@1wt.eu> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1940 Lines: 50 On Wed, Nov 04, 2015 at 10:17:06AM -0800, Andy Lutomirski wrote: > > That said I never feel completely comfortable with changing a file's > > permissions this way, I always fear it could break backup/restore > > applications. Let's imagine for a minute that a restore does this : > > > > extract(const char *file_name, int file_perms) { > > fd = open(".tmpfile", O_CREAT, file_perms); > > mmap(fd); > > /* actually write file */ > > close(fd); > > unlink(real_file_name); > > rename(".tmpfile", file_name); > > } > > > > Yes I know it's not safe to do the chmod before writing to the file > > but we could imagine some situations where it makes sense to be done > > this way (eg: if the file is put into a protected directory), and > > anyway this possibility is provided by open() and creat() so it is > > legitimate to imagine these ones could exist. > > > > Such a change would slightly modify semantics and affect such use cases > > *if they exist*, just like using write() instead of mmap() would fail. > > We could imagine having a sysctl to disable this strengthening, but it > > is probably not the best solution for the long term either. > > I'd say that this is an acceptable breakage risk. Yes probably. > In any event, the > potential for data loss is limited to a bit of the file mode, When this bit is the one sudo's setuid, it becomes one of the most important bits on the whole system :-) > and > restore apps like that really don't deserve to work in the first > place. I absolutely agree for this specific case. I just wanted to raise this case so that we're sure not to oversee anything related to other similar but more justified use cases. Willy -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/