Куда в линуксе принято сохранять разделяемые между локальными пользователями изменяемые данные приложения? В Windows эту задачу решает ProgramData, а в линуксе? FHS смотрел, но ничего похожего не нашел
Здравствуйте, rudzuk, Вы писали:
R>Куда в линуксе принято сохранять разделяемые между локальными пользователями изменяемые данные приложения? В Windows эту задачу решает ProgramData, а в линуксе? FHS смотрел, но ничего похожего не нашел
/usr/share
/usr/local/share
Здравствуйте, kov_serg, Вы писали:
_>/usr/share _>/usr/local/share
Тут надо добавить, что эти каталоги доступны на запись только аккаунтам с повышенными правами, рядовые пользователи могут только читать (и это правильно). Если какой-то код или данные нужно разделять на чтение между пользователями, то внести их туда должен администратор при установке/настройке. А в винде ProgramData — в первую очередь неконтролируемая свалка для приложений, сделанных раздолбаями, которые до сих пор не научились правильно организовывать доступ, и лишь в последнюю — средство для разделения данных между пользователями.
Здравствуйте, kov_serg, Вы писали:
k> R>Куда в линуксе принято сохранять разделяемые между локальными пользователями изменяемые данные приложения? В Windows эту задачу решает ProgramData, а в линуксе? FHS смотрел, но ничего похожего не нашел
k> /usr/share k> /usr/local/share
У обычного юзера нет прав на запись сюда, а данные приложения изменяемые. Хочется избежать дублирования большого объема данных. Софт распространяется в виде appimage.
Здравствуйте, rudzuk, Вы писали:
k>> /usr/share k>> /usr/local/share
R>У обычного юзера нет прав на запись сюда, а данные приложения изменяемые.
А какова вообще модель разделения данных между пользователями? Если это для совместной работы в группе, то и общий каталог нужно делать для группы, с соответствующими правами доступа. Если же это нечто вроде свалки "для всех" (в том числе и сетевых гостей), то действительно ли это вытекает из логики работы приложения?
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ> R>У обычного юзера нет прав на запись сюда, а данные приложения изменяемые.
ЕМ> А какова вообще модель разделения данных между пользователями? Если это для совместной работы в группе, то и общий каталог нужно делать для группы, с соответствующими правами доступа. Если же это нечто вроде свалки "для всех" (в том числе и сетевых гостей), то действительно ли это вытекает из логики работы приложения?
Приложение работает с большим объемом данных, которые, на начальном этапе, загружаются из интернет. В процессе работы, приложение эти данные не изменяет, но, иногда, загружает обновления для них. Сейчас данные хранятся в ~/.local/share/appname, но очень хочется избежать дублирования данных, когда приложение используется несколькими локальными пользователями.
Здравствуйте, rudzuk, Вы писали:
R>Приложение работает с большим объемом данных, которые, на начальном этапе, загружаются из интернет.
Тогда было бы правильнее иметь независимую службу (демон), загружающую/обновляющую эти данные. Делать это непосредственно из приложения допустимо лишь в том случае, когда все без исключения пользователи системы (и локальные, и сетевые) являются доверенными, и никак не могут навредить.
Здравствуйте, rudzuk, Вы писали:
R>Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>> R>У обычного юзера нет прав на запись сюда, а данные приложения изменяемые.
ЕМ>> А какова вообще модель разделения данных между пользователями? Если это для совместной работы в группе, то и общий каталог нужно делать для группы, с соответствующими правами доступа. Если же это нечто вроде свалки "для всех" (в том числе и сетевых гостей), то действительно ли это вытекает из логики работы приложения?
R>Приложение работает с большим объемом данных, которые, на начальном этапе, загружаются из интернет. В процессе работы, приложение эти данные не изменяет, но, иногда, загружает обновления для них. Сейчас данные хранятся в ~/.local/share/appname, но очень хочется избежать дублирования данных, когда приложение используется несколькими локальными пользователями.
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ> Тогда было бы правильнее иметь независимую службу (демон), загружающую/обновляющую эти данные. Делать это непосредственно из приложения допустимо лишь в том случае, когда все без исключения пользователи системы (и локальные, и сетевые) являются доверенными, и никак не могут навредить.
Навредить не реально, данные имеют цифровую подпись.
Здравствуйте, Михaил, Вы писали:
М> R>Приложение работает с большим объемом данных, которые, на начальном этапе, загружаются из интернет. В процессе работы, приложение эти данные не изменяет, но, иногда, загружает обновления для них. Сейчас данные хранятся в ~/.local/share/appname, но очень хочется избежать дублирования данных, когда приложение используется несколькими локальными пользователями.
М> Звучит как кандидат для /var/caches/ или /var/tmp
Здравствуйте, rudzuk, Вы писали:
R>Здравствуйте, Михaил, Вы писали:
М>> R>Приложение работает с большим объемом данных, которые, на начальном этапе, загружаются из интернет. В процессе работы, приложение эти данные не изменяет, но, иногда, загружает обновления для них. Сейчас данные хранятся в ~/.local/share/appname, но очень хочется избежать дублирования данных, когда приложение используется несколькими локальными пользователями.
М>> Звучит как кандидат для /var/caches/ или /var/tmp
R>Обе локации не гарантируют длительного хранения.
если пользователь вручную не удалит, они никуда не денутся. как и с програмдата
Здравствуйте, Михaил, Вы писали:
М>>> Звучит как кандидат для /var/caches/ или /var/tmp
R>>Обе локации не гарантируют длительного хранения.
М>если пользователь вручную не удалит, они никуда не денутся. как и с програмдата
Здравствуйте, Михaил, Вы писали:
М> М>> Звучит как кандидат для /var/caches/ или /var/tmp
М> R>Обе локации не гарантируют длительного хранения.
М> если пользователь вручную не удалит, они никуда не денутся. как и с програмдата
Про /var/tmp написано:
Although data stored in /var/tmp is typically deleted in a site-specific manner, it is recommended that deletions occur at a less frequent interval than /tmp.
R>Навредить не реально, данные имеют цифровую подпись.
И прям стопроцентов уверены что проверка не уязвима например к TOCTOU?
А если например какой нить злой юзер положит ковявые файлы или пермишены на них. Все остальные смогут работать или таки DoS атака окажется успешной?
Как много веселых ребят, и все делают велосипед...
Здравствуйте, rudzuk, Вы писали:
R>В /var/cache доступа на запись нет.
Создайте инсталлятором папку /var/cache/myprogram и дайте ей нужные права, хоть 777 (но лучше 770 и создать отдельную группу для пользователей вашей программы).
Здравствуйте, ononim, Вы писали:
R>>Навредить не реально, данные имеют цифровую подпись. O>И прям стопроцентов уверены что проверка не уязвима например к TOCTOU?
Сначала читаем в память, потом проверяем и потом используем из памяти.
O>А если например какой нить злой юзер положит ковявые файлы или пермишены на них. Все остальные смогут работать или таки DoS атака окажется успешной?
Загружаем заново и кладём на нужное место. Злой юзер сможет потратить трафик.
Вообще защищаться от злого юзера — тухлое дело. Защищаться надо от глупого юзера. Который что-то по ошибке может сделать. Например почистить эти самые кеши какой-нибудь кривой командой вроде echo > /var/caches/myprogram/download000.dat А если он реально злой — тут вы, скорей всего, уже проиграли. Потому, что он заюзает какой-нибудь local escalation exploit которых слишком много, чтобы считать их теоретическими и вот уже он злой root.
Здравствуйте, ononim, Вы писали:
o> R>Навредить не реально, данные имеют цифровую подпись.
o> И прям стопроцентов уверены что проверка не уязвима например к TOCTOU?
Прям уверены.
o> А если например какой нить злой юзер положит ковявые файлы или пермишены на них. Все остальные смогут работать или таки DoS атака окажется успешной?
Задачи оборонятся от пользователя нет. Пользователь достаточно хорошо мотивирован.
Здравствуйте, vsb, Вы писали:
vsb> Создайте инсталлятором папку /var/cache/myprogram и дайте ей нужные права, хоть 777 (но лучше 770 и создать отдельную группу для пользователей вашей программы).
Софт распространяется в виде appimage, инсталлятора нет.
o>> И прям стопроцентов уверены что проверка не уязвима например к TOCTOU? R>Прям уверены.
ну если уверены тогда ладно
o>> А если например какой нить злой юзер положит ковявые файлы или пермишены на них. Все остальные смогут работать или таки DoS атака окажется успешной? R>Задачи оборонятся от пользователя нет. Пользователь достаточно хорошо мотивирован.
тогда логиньте всех от рута и нет проблем
Как много веселых ребят, и все делают велосипед...