Re: allowing privileges on untrusted languages

Поиск
Список
Период
Сортировка
От Craig Ringer
Тема Re: allowing privileges on untrusted languages
Дата
Msg-id 5105FB69.2040108@2ndQuadrant.com
обсуждение исходный текст
Ответ на Re: allowing privileges on untrusted languages  (Robert Haas <robertmhaas@gmail.com>)
Ответы Re: allowing privileges on untrusted languages  (Robert Haas <robertmhaas@gmail.com>)
Список pgsql-hackers
<div class="moz-cite-prefix">On 01/28/2013 02:15 AM, Robert Haas wrote:<br /></div><blockquote
cite="mid:CA+TgmobAdQkSmoFPY_OhtWPzJPcGZoMZ7UQsUfj+ZzQWRmrcwQ@mail.gmail.com"type="cite"><br /><pre wrap="">I am not
surewhether it's really true that a capability mechanism
 
could "never really satisfy" anyone.  It worked for Linux.</pre></blockquote> I have no concern about using a
capabilitiesapproach for this, but I don't think Linux is a great example here. Linux's capabilities have been defined
ina somewhat ad-hoc fashion and a huge amount of stuff is bundled into CAP_SYS_ADMIN. Several capabilities provide
escalationroutes to root / CAP_SYS_ADMIN. See:<br /><br /><a
href="https://lwn.net/Articles/486306/">https://lwn.net/Articles/486306/</a><br/><a
href="http://dl.packetstormsecurity.net/papers/attack/exploiting_capabilities_the_dark_side.pdf">http://dl.packetstormsecurity.net/papers/attack/exploiting_capabilities_the_dark_side.pdf</a><br
/><br/> There's nothing wrong with capability systems, it's just clear that they need to be designed, documented and
maintainedcarefully. Adding ad-hoc capbilities is exactly the wrong route to take, and will lead us into the same mess
Linuxis in now.<br /><blockquote cite="mid:CA+TgmobAdQkSmoFPY_OhtWPzJPcGZoMZ7UQsUfj+ZzQWRmrcwQ@mail.gmail.com"
type="cite"><prewrap="">But, I think event triggers are a credible answer, too, and they
 
certainly are more flexible.</pre></blockquote> Yes,  but with the caveat that leaving security design to user triggers
willprovide users with more opportunities for error - failure to think about schemas and search_path, testing role
membershipvia some hacked-together queries instead of the built-in system information functions, failure to consider
SECURITYDEFINER and the effect of session_user vs current_user, etc. Some docs on writing security triggers and some
standardtriggers in an extension module would go a long way to mitigating that, though. The appeal of the trigger based
approachis that it means core doesn't land up needing
CAP_CAN_EXECUTE_PLPERLU_ON_TUESDAYS_AFTER_MIDDAY_ON_A_FULL_MOON_IN_A_LEAPYEAR.<br/><br /><pre class="moz-signature"
cols="72">--Craig Ringer                   <a class="moz-txt-link-freetext"
href="http://www.2ndQuadrant.com/">http://www.2ndQuadrant.com/</a>PostgreSQLDevelopment, 24x7 Support, Training &
Services</pre>

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

Предыдущее
От: Steve Singer
Дата:
Сообщение: Re: logical changeset generation v4 - Heikki's thoughts about the patch state
Следующее
От: Peter Geoghegan
Дата:
Сообщение: Re: Re: Doc patch making firm recommendation for setting the value of commit_delay