lists.openwall.net | lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC | |
Open Source and information security mailing list archives
| ||
|
Message-ID: <AANLkTinkHQ2tqAzqo77Bg_iyyYWUE72V85rTQqsEH4Nc@mail.gmail.com> Date: Tue, 28 Dec 2010 23:54:33 +0100 From: Olaf van der Spek <olafvdspek@...il.com> To: Neil Brown <neilb@...e.de> Cc: Christian Stroetmann <stroetmann@...olinux.com>, linux-fsdevel <linux-fsdevel@...r.kernel.org>, linux-ext4@...r.kernel.org, "Ted Ts'o" <tytso@....edu>, Nick Piggin <npiggin@...il.com> Subject: Re: Atomic non-durable file write API On Tue, Dec 28, 2010 at 11:31 PM, Neil Brown <neilb@...e.de> wrote: >> True, but all those exceptions (IMO) should be (proven to be) no problem. >> I'd prefer designs that don't have such exceptions. I may not be able >> to think of a concrete problem right now, but that doesn't mean such >> problems don't exist. > > Very true. But until such problems are described an understood, there is not > a lot of point trying to implement a solution. Premature implementation, > like premature optimisation, is unlikely to be fruitful. I know this from > experience. The problems seem clear. The implications not yet. >> >> I also don't understand why providing this feature is such a >> (performance) problem. >> Surely the people that claim this should be able to explain why. > > Without a concrete design, it is hard to assess the performance impact. I > would guess that those who anticipate a significant performance impact are > assuming a more feature-full implementation than you are, and they are > probably doing that because they feel that you need the extra features to > meet the actual needs (and so suggest those needs a best met by a DBMS rather > than a file-system). > Of course this is just guess work. With concreted reference points it is > hard to be sure. True, I don't understand why people say it will cause a performance hit but then don't want to tell why. >> >> > You seem to be asking for the ability to atomically change the data in a file >> > without changing the metadata. I cannot see why you would want this. Maybe >> > you could give an explicit use-case?? >> >> Where losing meta-data is bad? That should be obvious. >> Or where losing file owner is bad? Still thinking about that one. > > This is a bit left-field, but I think that losing metadata is always a good > thing. A file should contain data - nothing else. At all. Owner and access > permissions should be based on location as dictated by external policy.... > but yeah - off topic. In that case meta-data shouldn't be supported in the first place. > Clearly maintaining metadata by creating a new file and renaming in-place is > easy for root (chown/chmod/etc). So you are presumably envisaging situations > where a non-root user has write access to a file that they don't own, and > they want to make an atomic data-update to that file. > Sorry, but I think that allowing non-owners to write to a file is a really > really bad idea and providing extra support for that use-case is completely > unjustifiable. Isn't it quite common? Is preserving other meta-data really easy enough to be sure most apps do it? > If you want multiple people to be able to update some data you should have > some way to ask the owner to make an update. That could be: > - setuid program > - daemon which authenticates requests > - distributed workflow tool like 'git' where you speak to the owner > and ask them to pull updates. > > and there are probably other options. But un-mediated writes to a file you > don't own? Just say NO! Wouldn't that make Linux user groups quite useless? Olaf -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@...r.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists