[SSSD] [RFC] Add basic support for CI test execution

Jakub Hrozek jhrozek at redhat.com
Tue Jun 24 06:48:43 UTC 2014


On Wed, Jun 11, 2014 at 08:07:12PM +0300, Nikolai Kondrashov wrote:
> On 06/11/2014 06:19 PM, Lukas Slebodnik wrote:
> >On (11/06/14 17:28), Nikolai Kondrashov wrote:
> >>It will expand macros, which can include Lua scripts, and those can do
> >>basically anything. See http://www.rpm.org/wiki/PackagerDocs/RpmLua
> >>
> >>Try putting %{lua: os.execute('echo "Hello, world!"')} into a spec file and
> >>running "sudo yum-builddep" on it.
> >>
> >It isn't valid argument. You can execute a shell command from C source code.
> >     system("echo "Hello, world!");
> >
> >Solution:
> >We should not push any patch to CI without reading code.
> 
> This is not about *our* spec file. This is about enabling superuser access
> from user's account. This is about inciting the user to add a sudo rule
> essentially allowing execution of any code as root without asking for a
> password.

Where are the packages installed from? It's still only the repositories
that are enabled on the CI machine, right?

btw if you're concerned about CI running untrusted code as rpm scriptlets,
isn't the same issue with the code submitted? What if someone submits a
patch to CI that calls system(3) from one of the processes running as root?

Since the CI machinery runs inside Red Hat firewall, I'm not too
concerned about this part. Or did you plan on opening the CI to the
public?

> 
> A developer having added such a rule would be open to an attack such as
> installing a keylogger or a traffic sniffer. The attacker would only have to
> create a .spec file with the appropriate content and execute "sudo
> yum-builddep" on it under the user's account.
> 
> Also, with this approach the user would need to add *two* sudo rules instead
> of one: another one for "yum install".
> 
> Still, this is not the worst part of this, IMO, but the unnecessary complexity
> is.
> 
> >>>>A package missing from CI dependencies would be immediately obvious as CI
> >>>>builds would fail and it would be easy to then update the lists.
> >>>RPM dependencies are subset of CI dependencies.
> >>>
> >>>you can install CI dependencies with yum install and sssd dependencies with
> >>>yum-builddep
> >>
> >>Sure, but this will be more complicated than just installing them with
> >>yum-builddep.
> >>
> >Sorry,
> >You did not persuade me.
> >I still prefer to to reuse build dependencies from spec file.
> 
> I prefer avoiding duplication wherever possible myself, but in this case I
> think it is not worth it. Besides, with the alternative approach we would in
> fact be creating duplication of the package list sources and .spec file
> processing code.

I realize we still need to maintain the list for other distributions.

How, from a CI user perspective would I submit a patch to CI that needs
an additional dependency?

> 
> >In spec file, you can use different packages for different OS.
> >e.g.
> >   %if 0%{?rhel5_minor} >= 7
> >   BuildRequires: openldap24-libs-devel
> >   %else
> >   BuildRequires: openldap-devel
> >   %endif
> >
> >Everything is possible to solve it in bash script, but it will be another
> >complication. This is a reason why I want to avoid any duplicity.
> 
> So far we don't have any conditionals, but I think we can tolerate a few
> without tipping the complexity scale. Especially considering we're branching
> for distro families anyway.
> 
> Let's also hear what others have to say.

Sorry for the delay, this is one of the last threads I have in the
backlog since my vacation.



More information about the sssd-devel mailing list