Повышение привилегий в веб-среде для доступа к файлам

Question

Повышение привилегий в веб-среде для доступа к файлам

1

У меня есть ситуация, когда я хотел бы поднять права, которые у меня есть в веб-среде, чтобы я мог получить доступ к последовательному устройству.

В конкретном случае у меня есть веб-интерфейс для настройки модема, который появляется на /dev/ttyUSB[0-9].

Ноль или более модемов будут подключены конечным пользователем. Я пишу какое-то программное обеспечение, способное распознавать USB-модем, читая /sys/devices и разговаривая с модемом, используя некоторые AT-команды.

Я хотел бы открыть устройство и сделать что-то вроде:

ser = serial.Serial(tty, baudrate=115200, timeout=10)
ser.write('AT+CGSN\r\n')
imei = ser.readline()

Проблема заключается в том, что pyserial делает это: self.fd = os.open(self.portstr, os.O_RDWR|os.O_NOCTTY|os.O_NONBLOCK), чтобы открыть последовательный порт, где portstr /dev/ttyUSB0, но он делает это как пользователь nobody, который непривилегирован.

Последовательные порты этой системы принадлежат root: uucp и установлены как 0660 (т.е. rw-rw----).

Каков наилучший способ для пользователя, такого как nobody, у кого должно быть как можно меньше разрешений, чтобы открыть файл в dev?

Идеи, которые я буду рассматривать:

Выполнение действий в подпроцессе с помощью sudo.
Изменение разрешений файлов в /dev/ (инструкции по правильному использованию udev оценены!)
Используя другой API или часть программного обеспечения, которое я не рассматривал.

Jerub 10 март 2009, в 06:29

Источник

Теги:

python

permissions

linux

cgi

serial-port

5 ответов

2

Есть и другой способ: Unix/Linux позволяет отправлять дескрипторы файлов через сокеты Unix. Там даже модуль Perl для этого: PassAccessRights.pm. Не удалось найти аналогичный модуль для Python, но его можно было легко реализовать.

Eugene Morozov 10 март 2009, в 09:11

0

Интересная идея. У меня есть код, необходимый для передачи файловых дескрипторов через сокеты Unix, но если бы я зашел так далеко, я бы в конечном итоге просто выполнил работу в демоне и связался через механизм RPC.
Jerub 10 март 2009, в 13:01

2

В этом случае я бы написал демон, который запускал системный пользователь, который принимал сокетные соединения и передавал их на соответствующее устройство, а затем использовал сокеты в веб-приложении для общения с демоном. Это также помогает блокировать веб-приложение при открытии устройства, которое не совсем готово к работе с пользователями, разрешить блокировки немного более безопасно, чем вы могли бы с CGI и т.д.

Однако, если вы хотите предоставить приложению возможность напрямую общаться с устройствами, дайте им те же разрешения, что и null.

Tim Post 10 март 2009, в 05:55

0

Это, вероятно, самая реальная идея, предложенная на данный момент.
Jerub 10 март 2009, в 13:01

1

"Каков наилучший способ для пользователя, такого как никто, у кого должно быть как можно меньше разрешений, чтобы открыть файл в dev?"

На самом деле вам лучше использовать mod_wsgi в демонском режиме для вашего веб-приложения. Пользователь mod_wsgi может быть любым пользователем (и группой), которое вы предоставляете.

Вы можете работать как пользователь с соответствующими правами.

См. http://code.google.com/p/modwsgi/wiki/ConfigurationDirectives#WSGIDaemonProcess

S.Lott 10 март 2009, в 06:55

0

Фу, идея в том, что пользователь остается непривилегированным. Если бы я хотел запускать веб-скрипты от имени другого пользователя, я бы сделал это. Идея состоит в том, чтобы предоставить пользователю как можно меньше возможностей.
Jerub 10 март 2009, в 13:00
0

Верный. С именами и группами пользователей mod_wsgi вы даете им как можно меньше привилегий.
S.Lott 10 март 2009, в 13:19
0

У меня уже есть пользователь с несколькими разрешениями. Я хочу дать им немного больше прав в одном контексте - не повышать его разрешения для каждого веб-скрипта Python. Я не понимаю, почему вы думаете, что это решение моей проблемы?
Jerub 11 март 2009, в 21:48
0

@Jerub: я думаю, что это решение, потому что оно позволяет связать конкретного демона mod_wsgi с определенным именем пользователя и определенными разрешениями этого пользователя. Похоже, вы хотите, чтобы скрипт имел определенный набор разрешений. Это один из способов достижения этого.
S.Lott 11 март 2009, в 22:20
0

При использовании режима демона у вас может быть несколько групп процессов, работающих с разными привилегиями, и вы можете выбирать, какие URL-адреса перенаправляются на какой. Таким образом, вы могли бы направить только URL-адрес, которому необходимы эти специальные разрешения, к группе процессов демона, работающей с привилегией группы uucp. Все остальные URL-адреса могут быть направлены менее привилегированным пользователям. Недавние mod_wsgi даже имеют опциональные группы в режиме демона, так что вы можете быть достаточно конкретными о дополнительных группах, в которых работает пользователь. Другими словами, пользователь все еще может быть чем-то непривилегированным и полагаться только на группы.
Graham Dumpleton 03 окт. 2012, в 01:03

Показать ещё 3 комментария

-2

Идея sudo может быть возможна. IIRC, вы можете установить определенные команды для использования, но не требуя пароля.

Другой вариант - поставить nobody в группу, которая имеет доступ к требуемому устройству, или запустить Apache как группу, которая имеет доступ.

Если вы используете fastcgi (или equiv), я думаю, вы можете запустить скрипты как владеющий пользователь (некоторые общие хосты делают это).

Чтобы изменить разрешения файлов в /dev, просто chmod.

Richard Levasseur 10 март 2009, в 04:05

Ещё вопросы

Интересная идея. У меня есть код, необходимый для передачи файловых дескрипторов через сокеты Unix, но если бы я зашел так далеко, я бы в конечном итоге просто выполнил работу в демоне и связался через механизм RPC.
Это, вероятно, самая реальная идея, предложенная на данный момент.
Фу, идея в том, что пользователь остается непривилегированным. Если бы я хотел запускать веб-скрипты от имени другого пользователя, я бы сделал это. Идея состоит в том, чтобы предоставить пользователю как можно меньше возможностей.
Верный. С именами и группами пользователей mod_wsgi вы даете им как можно меньше привилегий.
У меня уже есть пользователь с несколькими разрешениями. Я хочу дать им немного больше прав в одном контексте - не повышать его разрешения для каждого веб-скрипта Python. Я не понимаю, почему вы думаете, что это решение моей проблемы?
@Jerub: я думаю, что это решение, потому что оно позволяет связать конкретного демона mod_wsgi с определенным именем пользователя и определенными разрешениями этого пользователя. Похоже, вы хотите, чтобы скрипт имел определенный набор разрешений. Это один из способов достижения этого.
При использовании режима демона у вас может быть несколько групп процессов, работающих с разными привилегиями, и вы можете выбирать, какие URL-адреса перенаправляются на какой. Таким образом, вы могли бы направить только URL-адрес, которому необходимы эти специальные разрешения, к группе процессов демона, работающей с привилегией группы uucp. Все остальные URL-адреса могут быть направлены менее привилегированным пользователям. Недавние mod_wsgi даже имеют опциональные группы в режиме демона, так что вы можете быть достаточно конкретными о дополнительных группах, в которых работает пользователь. Другими словами, пользователь все еще может быть чем-то непривилегированным и полагаться только на группы.

James Cameron · Accepted Answer · 2009-03-11T19-40-00.000Z

Настроить правило udev, чтобы chgrp нового устройства никому, если приемлемо, чтобы каждому доступу через веб-интерфейс разрешался тот же доступ к устройству. Вот что я вложил в свой пакет eee-bpw в файл /etc/udev/rules.d/99-bpw.rules.

# Sierra Wireless AirCard 880 U
BUS=="usb", KERNEL=="ttyUSB2*", ACTION=="add", \
   PRODUCT=="1199/6855/0", DEVNAME=="/dev/tts/USB2", \
   OWNER="root", GROUP="dialout", \
   SYMLINK+="bpw", RUN="/usr/sbin/bpw"

Заменить кого-либо для dialout. В этом конкретном правиле предполагается, что имя устройства будет /dev/ttyUSB 2, но вы можете значительно расширить это правило, см. Документацию udev.