Трубопроводи Дженкінса CI не дозволяється використовувати метод groovy.lang.GroovyObject


105

Я використовую Jenkins 2 для компіляції Java-проектів, я хочу прочитати версію з pom.xml, я дотримувався цього прикладу:

https://github.com/jenkinsci/pipeline-plugin/blob/master/TUTORIAL.md

Приклад пропонує:

Повний конвеєр Дженкінса з проблемною функцією кружляв

Здається, що існує певна проблема із захистом доступу до файлової системи, але я не можу зрозуміти, що це (або чому) дана проблема:

Я просто трішки відрізняюся від прикладу:

def version() {
    String path = pwd();
    def matcher = readFile("${path}/pom.xml") =~ '<version>(.+)</version>'
    return matcher ? matcher[0][1] : null
}

Помилка, яку я отримую під час запуску методу 'версія':

org.jenkinsci.plugins.scriptsecurity.sandbox.RejectedAccessException: Scripts not permitted to use method groovy.lang.GroovyObject invokeMethod java.lang.String java.lang.Object (org.codehaus.groovy.runtime.GStringImpl call org.codehaus.groovy.runtime.GStringImpl)
    at org.jenkinsci.plugins.scriptsecurity.sandbox.whitelists.StaticWhitelist.rejectMethod(StaticWhitelist.java:165)
    at org.jenkinsci.plugins.scriptsecurity.sandbox.groovy.SandboxInterceptor.onMethodCall(SandboxInterceptor.java:117)
    at org.jenkinsci.plugins.scriptsecurity.sandbox.groovy.SandboxInterceptor.onMethodCall(SandboxInterceptor.java:103)
    at org.kohsuke.groovy.sandbox.impl.Checker$1.call(Checker.java:149)
    at org.kohsuke.groovy.sandbox.impl.Checker.checkedCall(Checker.java:146)
    at com.cloudbees.groovy.cps.sandbox.SandboxInvoker.methodCall(SandboxInvoker.java:15)
    at WorkflowScript.run(WorkflowScript:71)
    at ___cps.transform___(Native Method)
    at com.cloudbees.groovy.cps.impl.ContinuationGroup.methodCall(ContinuationGroup.java:55)
    at com.cloudbees.groovy.cps.impl.FunctionCallBlock$ContinuationImpl.dispatchOrArg(FunctionCallBlock.java:106)
    at com.cloudbees.groovy.cps.impl.FunctionCallBlock$ContinuationImpl.fixArg(FunctionCallBlock.java:79)
    at sun.reflect.GeneratedMethodAccessor408.invoke(Unknown Source)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke(Method.java:601)
    at com.cloudbees.groovy.cps.impl.ContinuationPtr$ContinuationImpl.receive(ContinuationPtr.java:72)
    at com.cloudbees.groovy.cps.impl.FunctionCallBlock$ContinuationImpl.dispatchOrArg(FunctionCallBlock.java:100)
    at com.cloudbees.groovy.cps.impl.FunctionCallBlock$ContinuationImpl.fixArg(FunctionCallBlock.java:79)
    at sun.reflect.GeneratedMethodAccessor408.invoke(Unknown Source)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke(Method.java:601)
    at com.cloudbees.groovy.cps.impl.ContinuationPtr$ContinuationImpl.receive(ContinuationPtr.java:72)
    at com.cloudbees.groovy.cps.impl.ContinuationGroup.methodCall(ContinuationGroup.java:57)
    at com.cloudbees.groovy.cps.impl.FunctionCallBlock$ContinuationImpl.dispatchOrArg(FunctionCallBlock.java:106)
    at com.cloudbees.groovy.cps.impl.FunctionCallBlock$ContinuationImpl.fixArg(FunctionCallBlock.java:79)
    at sun.reflect.GeneratedMethodAccessor408.invoke(Unknown Source)

Я використовую ці версії: Plugin Pipeline 2.1 Jenkins 2.2


У мене була схожа помилка Scripts not permitted to use method, але це сталося тому, що я писав scm 'checkout'замість цього checkou scm. На всякий випадок, якщо хтось потрапить на це, стежте за поганим синтаксисом :). Виконання, як сказав Маартен Кієфт, дозволило мені побачити більш чітке повідомлення про помилку щодо поганої команди :)
GabLeRoux

Відповіді:


262

Швидке виправлення

У мене була подібна проблема, і я вирішив її, зробивши наступне

  1. Перейдіть до джинкінів> Керуйте джинкінами> Підтвердження сценарію в процесі роботи
  2. Була відкладена команда, яку я повинен був затвердити.

Під час посилання на затвердження процесу в Дженкінс 2.61 Альтернатива 1: Вимкнути пісочницю

Як пояснюється в цій статті, глибокі сценарії за замовчуванням виконуються в режимі «пісочниці». Це означає, що підмножину методів groovy дозволяється запускати без схвалення адміністратора. Також можна запускати сценарії не в режимі «пісочниці», що означає, що весь сценарій повинен бути затверджений адміністратором відразу. Це заважає користувачам одночасно затверджувати кожен рядок.

Запуск сценаріїв без пісочниці можна виконати, знявши цей прапорець у конфігурації проекту трохи нижче вашого сценарію: введіть тут опис зображення

Альтернатива 2: Вимкнути безпеку сценарію

Як пояснюється в цій статті, також можна повністю відключити захист сценарію. Спочатку встановіть плагін безпеки скрипта, а потім змініть файл jenkins.xml і додайте цей аргумент:

-Dpermissive-script-security.enabled = true

Отже, ви jenkins.xml буде виглядати приблизно так:

<executable>..bin\java</executable>
<arguments>-Dpermissive-script-security.enabled=true -Xrs -Xmx4096m -Dhudson.lifecycle=hudson.lifecycle.WindowsServiceLifecycle -jar "%BASE%\jenkins.war" --httpPort=80 --webroot="%BASE%\war"</arguments>

Переконайтесь, що ви знаєте, що ви робите, якщо це реалізуєте!


1
Якщо схвалення всього сценарію краще, залежить від структури команди. Для кількох розробників з повним доступом це досить приємно. Але налаштування з декількома командами змусить адміністраторів схвалити кожну зміну всіх сценаріїв конвеєра.
Роджер Леманн

2
Альтернатива 3 (насправді має бути першою пропозицією) - це змінити проблемний код, що не міститься в списку . У цьому випадку досить простого використання @NonCPSдля Matcherвикористання. У цьому випадку немає необхідності відключати безпеку для всього трубопроводу, а особливо для всієї установки Дженкінса. Оцініть кожен заблокований дзвінок окремо і вирішіть, чи дійсно вам потрібно їх схвалити.
mkobit

1
@mkobit не працює для мене. @NonCPSне допомагає.
Варварюк

@warvariuc Хм, це може бути, якщо ти повертаєшся Matcherсам, бо Matcherне реалізує Serializableінтерфейс. Можливо, варто поставити нове запитання. Хочеться, щоб документація, на яку було посилається в первинному запитанні, зберігалася і не була помилковою для початку.
mkobit

2
@mkobit Я прикрасив NonCPS функцію, яка використовує currentBuild.rawBuild.getCause(Cause.UserIdCause).getUserId(). NonCPS зовсім не допомагає з питаннями безпеки, з того, що я читав.
warvariuc

12

Потрібно вимкнути пісочницю для Groovy в конфігурації вашої роботи.

В даний час це неможливо для багатогалузевих проектів, де грувий сценарій походить від scm. Для отримання додаткової інформації див. Https://isissue.jenkins-ci.org/browse/JENKINS-28178


6

Я зіткнувся з цим, коли зменшив кількість параметрів вводу користувача у userInput з 3 до 1. Це змінило змінний тип виводу userInput з масиву на примітивний.

Приклад:

myvar1 = userInput['param1']
myvar2 = userInput['param2']

до:

myvar = userInput

Це саме виправлення симптому, який я відчув. Повідомлення про помилку було org.jenkinsci.plugins.scriptsecurity.sandbox.RejectedAccessException: Scripts not permitted to use method groovy.lang.GroovyObject invokeMethod java.lang.String java.lang.Object. Метод очікував 2 параметри і отримував 3.
Tyler W

4

Щоб обійти пісочницю скриптів, збережених у SCM Groovy, рекомендую запустити сценарій як команда Groovy (замість файлу Groovy Script ):

import hudson.FilePath
final GROOVY_SCRIPT = "workspace/relative/path/to/the/checked/out/groovy/script.groovy"

evaluate(new FilePath(build.workspace, GROOVY_SCRIPT).read().text)

у такому випадку, рихлий скрипт передається з робочої області до Майстра Дженкінса, де він може бути виконаний як system Groovy Script. Пісочниця придушується до тих пір, поки не буде встановлено прапорець Use Groovy Sandbox .


5
Це здається незграбним, ризикованим і обов'язково повернеться і вкусить вас.
Саймон Форсберг

4
Ну, безпека важлива, особливо коли вона захищає чутливі до користувача дані, але також має ціну, наприклад, ускладнення в процесі розробки. Коли інструмент безпеки лише наполовину реалізований, він стає ще гіршим. Пісочниця сценаріїв Дженкінса - прекрасний приклад наполовину реалізованих інструментів безпеки, і, як результат, вам може знадобитися повністю відключити цю функцію, оскільки в іншому випадку це означає, що для вас не йдеться.
Степан Вавра

3
У моєму випадку, після оновлення до більш старого Дженкінса, мій скрипт Groovy перестав працювати, і єдиним способом змусити його працювати було б запустити сценарій 300 разів (лише оцінка) і для кожного запуску натиснути на інтерфейс Jenkins, щоб дозволити весь метод викликає сценарій у 200 рядків. Більше того, інтерфейс користувача не дозволяє вставити повний список усіх дозволених викликів методів у випадку, якщо ви змогли якось їх генерувати. Крім того, інтерфейс користувача перестав показувати деякі виклики методу, і через деякий час я не зміг продовжити.
Степан Вавра
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.