Re: Securing "make check" (CVE-2014-0067)

Поиск
Список
Период
Сортировка
От Noah Misch
Тема Re: Securing "make check" (CVE-2014-0067)
Дата
Msg-id 20140304154506.GA3490704@tornado.leadboat.com
обсуждение исходный текст
Ответ на Re: Securing "make check" (CVE-2014-0067)  (Tom Lane <tgl@sss.pgh.pa.us>)
Список pgsql-hackers
On Mon, Mar 03, 2014 at 08:15:41PM -0500, Tom Lane wrote:
> Noah Misch <noah@leadboat.com> writes:
> > On Mon, Mar 03, 2014 at 01:29:00AM -0500, Tom Lane wrote:
> >> What I was envisioning was that we'd be relying on the permissions of the
> >> containing directory to keep out bad guys.  Permissions on the socket
> >> itself might be sufficient, but what does it save us to assume that?
> 
> > My first preference is to use the simplest code that POSIX requires to have
> > the behavior we desire.  POSIX specifies as implementation-defined whether
> > connect() checks filesystem permissions.  That's true of both directory search
> > permissions and permissions on the socket itself.
> 
> Surely you are misinterpreting that.  If it worked as you suggest,
> connect() would provide a trivial method of bypassing directory
> permissions, at least to the extent of being able to probe for the
> existence of files within supposedly-unreadable directories.  I can
> believe that there are implementations that don't examine the permissions
> on the socket file itself, but not that there are any that disregard
> directory permissions during the file lookup.

Wherever POSIX makes something implementation-defined, it is possible to
design a conforming system with detestable properties.  That does not shake
the fact that this behavior is indeed implementation-defined.

> > I found no evidence either way concerning the prevalence of systems that
> > ignore directory search permissions above sockets.
> 
> That's because the question is ridiculous on its face, so nobody ever
> bothered to address it.  I think the burden is on you to show that there
> has ever been any system that read the spec the way you propose.

I doubt any exist.

> > I don't care for interposing a directory based solely on the fact that some
> > ancient systems needed that.  Changing unix_socket_permissions is a one-liner
> > in each test driver.  Placing the socket in a directory entails setting PGHOST
> > in the psql and postmaster environments and cleaning up the directory on exit.
> 
> Placing the socket anywhere besides the default location will require
> setting PGHOST anyway, so I don't see that this argument holds much water.

If we have moved the socket anyway, then the costs of moving the socket
vanish?  Yes, yes they do...

Your responses have not added to this thread.

-- 
Noah Misch
EnterpriseDB                                 http://www.enterprisedb.com



В списке pgsql-hackers по дате отправления:

Предыдущее
От: Fabrízio de Royes Mello
Дата:
Сообщение: Re: GSoC proposal - "make an unlogged table logged"
Следующее
От: Atri Sharma
Дата:
Сообщение: Re: ALTER TABLE lock strength reduction patch is unsafe