* Alvaro Herrera (alvhe...@2ndquadrant.com) wrote: > Robert Haas wrote: > > On Wed, Oct 29, 2014 at 10:52 AM, Andres Freund <and...@2ndquadrant.com> > > wrote: > > >> The larger point though is that this is just one of innumerable attack > > >> routes for anyone with the ability to make the server do filesystem reads > > >> or writes of his choosing. If you think that's something you can safely > > >> give to people you don't trust enough to make them superusers, you are > > >> wrong, and I don't particularly want to spend the next ten years trying > > >> to wrap band-aids around your misjudgment. > > > > > > ... but that doesn't necessarily address this point. > > > > I think the question is "just how innumerable are those attack > > routes"? So, we can prevent a symlink from being used via O_NOFOLLOW. > > But what about hard links? > > Users cannot create a hard link to a file they can't already access.
The specifics actually depend on (on Linux, at least) the value of /proc/sys/fs/protected_hardlink, which has existed in upstream since 3.6 (not sure about the RHEL kernels, though I expect they've incorporated it also at some point along the way). There is a similar /proc/sys/fs/protected_symlinks control for dealing with the same kind of time-of-check / time-of-use issues that exist with symlinks. At least on my Ubuntu 14.04 systems, these are both set to '1'. Thanks, Stephen
signature.asc
Description: Digital signature