Чому ж привілейована команда bash дає різну інформацію від сценарію, ніж з командного рядка?

0

Я написав bash-скрипт, щоб перевірити різні конфігурації в системі, але я отримую різні результати в залежності від того, чи він запускається з командного рядка безпосередньо або зі сценарію. Ось команда:

bt_discoverable=$(system_profiler SPBluetoothDataType | grep Discoverable)

Якщо вимкнути виявлення на Bluetooth, а потім передати змінну в командному рядку, я отримаю очікуваний результат:

Discoverable: No

Але якщо я повторюю його відразу після запуску тієї ж команди з скрипта bash, я отримую

Discoverable: Yes

Сценарій підвищує свої привілеї через внутрішню функцію sudo, тому я прокоментував блок для цієї функції і запустив сценарій знову. Цього разу справи працювали так, як повинні. Ось функція висоти:

RunAsRoot()
{
        if [[ "${USER}" != "root" ]] ; then
                echo
                echo
                echo "***  Type the password for ${USER} and press ENTER  ***"
                echo
                sudo $1 && exit 0
        fi
}
RunAsRoot $0

Ця функція є першою справою, яку виконує скрипт, тому позиція коду є проблемою.

Чому при запуску в підвищених привілеях (під) оболонка викликає цю проблему? Це проблема терміналу, Bash, або щось ще я не знаю?

terminal bash

— лабіринт
джерело

2

Я вважаю, що проблема може виникнути в підзборі, оскільки вона є підгрупою як коренем, а не поточним користувачем. Оскільки в ньому зберігається логічне значення "Discoverable" ~/Library/Preferences/ByHost/com.apple.BlueTooth.<uuid>, можливо, користувач root тимчасово створює свій власний файл BlueTooth, перебуваючи в підпідниці, і ваш скрипт перевіряє це значення замість того, щоб користувач увійшов у повну версію OS X. Я сподіваюся, що це має сенс, і це лише здогадка. :) Які речі у вашому сценарії вимагають root? Особливо, якщо ви просто перевіряєте значення system_profiler?

— Thankyour

це прив'язка сценарію, щоб перевірити, що маки в школах успішно налаштовані і прив'язані до домену AD. dsconfigad вимагає цього хоча б на деяких версіях, навіть якщо це лише інформаційний сценарій.

— Лабіринт

1

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

Завдяки "дякуємо" за це. Я нарешті відправив це як відповідь, оскільки вони не протягом декількох тижнів.

— лабіринт
джерело

0

Це мій шлях

bt_discoverable=$(system_profiler SPBluetoothDataType | grep Discoverable)

sudoMe()
{
    if [[ "${USER}" != "root" ]]; then
    echo "inside...as: $USER"
    sudo $0 && sudoBack

    fi
}

doAsRoot(){
    if [[ "${USER}" == "root" ]]; then
        echo "this as $USER"
    fi
}

sudoBack(){
    if [[ "${USER}" == "root" ]]; then
        echo "reverse...from: $USER"
        sudo -k && exit 0
    fi
}

discover() {
    echo $bt_discoverable
}

sudoMe 
doAsRoot
sudoBack
discover

sudoMeзнову підніметься до rootвиклику сценарію.
Усі наступні функції, такі як doAsRootповинні перевірити $USER == root, в іншому випадку буде працювати в перший виклик сценарію, як виклик $ USER.
sudoBack підніметься, використовуючи sudo -k
Усі наступні функції, як discoverтепер, виконуються як перші$USER

Якщо ми викликаємо як root, як у відповіді, ІМХО не може повернутися до sudo -kбудь-якої частини сценарію. Я протестував, але не міг знайти жодного ;-)

— Марко М. Хаген
джерело