switch from using ~/.far2l/tmp to /tmp or /var/tmp

[unxed]

No description provided.

[invy]

Wanted to report and always forgot :)

Basically set to $TMP or how environment variable is called.

[elfmz]

Its not so easy. In order to avoid data leak new directory should be created in temp with denied 'everyone' read access. Also necessary to handle pre-existing directory again in some secure manner - verify its mode&ownership, and don't use it if its incorrect.

[unxed]

not sure if it is far2l's problem to handle this.
for ubuntu and derivatives there is pam-tmpdir package that manages personal tmp folders per user
https://launchpad.net/ubuntu/+source/pam-tmpdir

[invy]

It's not far concern definitively. If you need to avoid data leakage, mount your own tmp eventually even in tmpfs.

[elfmz]

In mult-user system there can be many users using system together. And unless they're roots, each user should not see data and even file names that another user opens at same moment. Possible attacks include cases when malicious user creates directories/files with names matching to autogenerated by app, running under victim's account.

[invy]

Since far targets single-user-desktops at the moment it's not an issue.
Other then that it's not difficult to create tmp directory inside /tmp and set correct permissions...

mkdir $TMP/far2l-$username
chmod 700 $TMP/far2l-$username

It will be even more secure, then simply in $home/.far2l/tmp, because home is accessible for the group and for others!

% ls -lh ~/.far2l | grep tmp
drwxrwxr-x 4 igor igor 4,0K Okt 22 00:35 tmp

[elfmz]

I dont say its too difficult, just need some hustling
BTW from 1st look MC implemented this correctly.

[unxed]

using ~/.far2l/tmp as temporary files storage is not suiteble for SSD users that mount /tmp as tmpfs to save write cycles of device.

[unxed]

maybe ~/.cache/far2l is the better place for temporary storage then ~./far2l/tmp anyway?
storing ~/.cache in tmpfs is popular approach for SSD users also.

and ~/.config/far2l for all other files from ~/.far2l, maybe?

https://debian-handbook.info/browse/stable/sect.filesystem-hierarchy.html

This specification states that configuration files should be stored under ~/.config, cache files under ~/.cache, and application data files under ~/.local (or subdirectories thereof).

this is how google chrome behaves, for example, comparing to mozilla, who inexplicably store everything except cache in ~ (but still store cache inside ~/.cache)

[invy]

cache has completely different purpose, it stores data, which are relevant throughout multiple runs and instances. For browser it's for example cached images. On the other hand data in tmp are needed only once at the moment, for example, extracted files from an archive.

[unxed]

ok, that about moving from ~/.far2l to ~/.config/far2l as suggested by debian recommendations?

[invy]

Yep, the ~/.config directory is the right choice for all of the configs. I would create another ticket for it.

[unxed]

Yep, the ~/.config directory is the right choice for all of the configs. I would create another ticket for it.

#181

systemd is capable to manage personal tmp's per service, using folders like
/var/tmp/systemd-private-93009396314b437fbe32a92627699ea2-rtkit-daemon.service-25G6sD/tmp/
may be this feature can be used somehow?

[invy]

I wouldn't make far2l dependable on systemd. It's too big dependency and there is no reason to use it. If you would like to put some large dependencies, then I'd go with boost (and massively refactor far to use it.)
http://stackoverflow.com/a/11335566

// Boost.Filesystem VERSION 3 required
#include <string>
#include <boost/filesystem.hpp>
boost::filesystem::path temp = boost::filesystem::unique_path();
const std::string tempstr    = temp.native();  // optional

Or use basic solution as I've described earlier: create directory inside of the $TMP, name should contain "far2l", userid and pid, set it's permissions to 700 and it's done.

[lieff]

Ненадо boost, прошу. Я уже поимел секс собирая fastuidraw на некоторых устройсвах, по мне так это похуже systemd зависимость, на некоторых девайсах даже systemd есть, а с бустом проблемы. Посмотрел я сорсы unique_path(); в бусте, просто рандомные чиселки генерит, и из-за этого весь буст подключать?

[invy]

Большая часть boost'а - header library, потому с ней проблем быть не должно нигде. Мы его вот тоже в эмбеддед используем и отлично.

И не только из-за unique_path. Там куча всего хорошего - работа с симлинками и путями, например.

[unxed]

Or use basic solution as I've described earlier: create directory inside of the $TMP, name should contain "far2l", userid and pid, set it's permissions to 700 and it's done.

+1

[lieff]

Тем не менее не вся header library, тот же boost::filesystem без либы не взлетит. Основные проблемы начинаются когда рассчитывали на одну версию буста, а в репозитарии другая (ну или совсем нет). А для эмбебеда вы его сами собирали или он там уже был? И так всем теперь придется собирать, и если не повезет (в больших проектах обычно так и есть), собирать именно ту версию на которую было рассчитано.
Вот пример конфликта версий на sailfish kingsfordgroup/sailfish#91
Я уже не говорю о том что совместимость бинарника это убивает вообще почти в ноль. Если libstdc++ уже в очень большом количестве дистров есть статический и основная несовместимость бинарника упирается в версию glibc (c чем тоже можно бороться). То статического boost в репах я еще не видел. Совместимый бинарь уменьшает размер всякой фигни что надо тянуть во flatpak\snap пакетах, и делает deb\rpm который можно без модификации запустить на большем количестве дистров.
Из больших зависимостей остается еще wxWidgets, но для эмбебеда можно сделать серверную часть фара без зависимостей, а рисовальщик на клиенте. Это будет работать так же быстро как putty->ssh (я это сейчас делаю потихоньку, и boost мне жизни подпортит).

[lieff]

Вот утилка https://gist.github.com/lieff/843cf9d2c13f2139e3e2da7db2da6617 которая даунгрейдит необходимую версию glibc. После этого бинарь пойдет вообще везде.

[lieff]

Тэкс, немного наврал. Статический boost где то есть где-то нет, просто везде есть so и по дефолту везде линкуется с ними, чтобы подключить статические, не сломав остальную линковку надо еще попотеть. Для stdc++ специально на этот случай предусмотрен -static-libstdc++ и c++_static.

[invy]

Чем не устраивает динамический boost из репозиториев - не понятно. Все равно под новую систему - собирать надо и не морочить голову.

[unxed]

Naivly considered myself the most active issue flooder here :)

[lieff]

Я же написал чем - бинарь становится гораздо менее совместима. Так можно сделать один deb\rpm и он пойдет почти везде, а с бустом мало того что на меньшем количестве дистров пойдет из-за несовместимости версий в репах, так еще и в рамках одного дистра при обновлении буста придется обновлять и deb фара, при этом еще и код менять в некоторых случаях.
Насчет все равно под новую систему собирать - это все идеальная теория. На практике у тебя ограниченное число билд серверов, и пара неоф сборок на чемто еще от энтузиастов. Так что чем больше совместимые пакеты с них выйдут - тем лучше.
На маке тоже или внутрь буст эмбедить или статически линковать, иначе из коробки не запустится.
Еще пример: сколько раз я обновлял mc\htop\perf на sailfish? Нисколько, они просто работают. А зависели бы от буста - пришлось бы обновлять (и статического тут в репах нет). Причем perf собрать непросто, я юзаю чужой андройдовский порт (да, и он работает на sailfish, вот это я понимаю совместимость), ну и как мне его пересобрать? Пришлось бы тратить кучу времени. Вот хотелось бы чтобы и фар здесь был бы таким же совместимым, без wxWidgets он сейчас такой и есть.
В общем имхо не стоит оно того.