Hi! > > > > Consider FD passing over unix socket. Passing R/O file descriptor to > > > > the other task, then having the task write to the file is certainly bad. > > > > > > You've omitted the "R/O file descriptor of a file that is writable for > > > that other task" part... > > > > That is 666 for the other task. But the other task can't access it due > > to directory being 700 or something. Your fchdir() argument does not > > apply here. > > *snort* > > What you are advocating is a very limited class of setups that might be > usable for protecting files if not for the existing behaviour on a shitload > of systems. > > The thing is, that class *is* very limited. E.g. introduce links and it's > fallen apart. Introduce bindings and the same will happen. Just try to > extend it one level deeper and fchdir() will bite you, etc. All of that > is not dependent on procfs even being there. > > Access rights belong to file, not to a pathname (and there's no such thing > as _the_ pathname of a file). > > I'd buy that as a minor QoI issue; as a security one - no way. Ok, so you see it as a (QoI) problem, but not too major. Good; I hope it gets fixed one day. Pavel -- (english) http://www.livejournal.com/~pavelmachek (cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html -- To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
