Xdg runtime dir принадлежит не данному пользователю
I expect to be able to run systemsettings5 without it displaying that XDG_RUNTIME_DIR is not set.
Technical details
- system: "x86_64-linux"
- host os: Linux 4.13.4, NixOS, 17.09.git.39cd40f (Hummingbird)
- multi-user?: yes
- sandbox: no
- version: nix-env (Nix) 1.11.15
- channels(root): "nixos-17.09.2182.7f6f0c49f0"
- nixpkgs: /nix/var/nix/profiles/per-user/root/channels/nixos/nixpkgs
The text was updated successfully, but these errors were encountered:
jtojnar commented Jan 19, 2018
su removes the environment variables too.
smcv commented Jun 17, 2015
One situation where the state-file business could matter is if the way we construct XDG_RUNTIME_DIR changes, and an upgrade results in briefly running a new PAM module against XDG_RUNTIME_DIRs created by an old logind, or an old PAM module (in a long-running daemon) against XDG_RUNTIME_DIRs created by a newly restarted logind. I'd assumed that this sort of concern was why we didn't just do (API calls that end up with) the simple printf.
poettering commented Jun 17, 2015
I think we should probably create a call user_get_runtime_dir(uid_t uid, char **ret) in src/basic/login-util.[ch], and then use that in the PAM module and in logind, and then stop reading the /run file from the PAM module. That we make sure both sides use the same logic to come up with the dir, but they will no longer need synchronization.
smcv commented Jun 17, 2015
The first patch indeed should fix a bug.
Should, but doesn't, because I call:
but user_save() has:
and u->started hasn't been set TRUE yet.
I'll try to work out the least problematic way to fix this.
smcv commented Jun 17, 2015
We're doing a "transaction" in which we start the user's user-session. It looks as though we want to only write out /run/systemd/users/ after the transaction has been started successfully; but one of the things we do in the transaction is to StartUnit for user@.service, which can fail with ENOMEM or a D-Bus error, and we need the XDG_RUNTIME_DIR before we can rely on that to work.
- create the file earlier/more often (make the early-return not trigger in this particular case); or
- have a separate way to communicate the XDG_RUNTIME_DIR to system --user
coretemp commented Jan 19, 2018
A long time ago running something as root would do the same thing as running as a user (before XDG_ existed); I would expect them to not break that behavior or to simply refuse to run, because it is not a supported configuration to run in.
Now, when you run systemsettings5 as root, you don't see any icons being displayed for example, creating a degraded experience.
I don't know what systemsettings5 is supposed to do, but I would like it to either say "you are not supposed to run this as root", or run in some way in which it can run as root without any rendering defects. The current situation is that it just does something and it doesn't work.
I wasn't expecting to spend so much time on this, however, since it is only a minor issue. Perhaps a KDE developer could figure out what it is supposed to be doing?
переопределял для себя «кастомные» каталоги XDG_xxx - на RAM-DISK типа:
в Slackware 14.2+ выяснилось то, что значение переменной XDG_RUNTIME_DIR игнорируется и системой под эти цели принудительно используется каталог:
причем, если оставить «старое кастомное переопределение», то
KDE4/5 - будет игнорировать эту настройку и просто принципиально юзать «новый стандарт каталога»
а вот TDE-14.0.7 будет честно пытаться использовать «кастомную настройку»
причем, по умолчанию каталог
понятное дело, бодаться в лоб я не стал, использую «так как есть», и то, что «я чё-та да не знаю, Ё!»
но, хотелось бы услышать ваши мнения, идеи, все что думаете по этому поводу и, особенно, по поводу «а нахрена так делать?!» :о)
короче, просто поболагурим на «тему»
p.s. уточняю, мне непонятно (больше всего волнует) не то, что TDE глючит, а почему весь мир/все остальные принудительно, как по договоренности игнорируют XDG_RUNTIME_DIR :o)
$XDG_RUNTIME_DIR defines the base directory relative to which user-specific non-essential runtime files and other file objects (such as sockets, named pipes, . ) should be stored. The directory MUST be owned by the user, and he MUST be the only one having read and write access to it. Its Unix access mode MUST be 0700.
The lifetime of the directory MUST be bound to the user being logged in. It MUST be created when the user first logs in and if the user fully logs out the directory MUST be removed. If the user logs in more than once he should get pointed to the same directory, and it is mandatory that the directory continues to exist from his first login to his last logout on the system, and not removed in between. Files in the directory MUST not survive reboot or a full logout/login cycle.
The directory MUST be on a local file system and not shared with any other system. The directory MUST by fully-featured by the standards of the operating system. More specifically, on Unix-like operating systems AF_UNIX sockets, symbolic links, hard links, proper permissions, file locking, sparse files, memory mapping, file change notifications, a reliable hard link count must be supported, and no restrictions on the file name character set should be imposed. Files in this directory MAY be subjected to periodic clean-up. To ensure that your files are not removed, they should have their access time timestamp modified at least once every 6 hours of monotonic time or the 'sticky' bit should be set on the file.
If $XDG_RUNTIME_DIR is not set applications should fall back to a replacement directory with similar capabilities and print a warning message. Applications should use this directory for communication and synchronization purposes and should not place larger files in it, since it might reside in runtime memory and cannot necessarily be swapped out to disk.
1) $RAM_DISK/.var/run соответствует всем перечисленным требованиям?
2) еще момент — где задается? Должно быть непосредственно после входа пользователя. На этот момент $RAM_DISK содержит правильное значение?
bormant ★★★★★ ( 23.03.20 18:37:11 )
Последнее исправление: bormant 23.03.20 18:37:37 (всего исправлений: 1)
1й пункт из серии пермишнов для доступа пользователя и «тараканов» на предмет хочушек «сохранения или нет» . да, соотв. ВСЕМ. требованиям, как и до этого момента соответствовал и работал
хотя, не исключено, что-то упустил :о)
до Slackware 14.2+ не было никаких проблем
Должно быть непосредственно после входа пользователя
оно еще до того.
sunjob ★★★ ( 23.03.20 20:35:34 )
Последнее исправление: sunjob 23.03.20 20:39:14 (всего исправлений: 3)
p.s. уточняю, мне непонятно (больше всего волнует) не то, что TDE глючит, а почему весь мир/все остальные принудительно, как по договоренности игнорируют XDG_RUNTIME_DIR :o)
sudo и su пробовал, kdesu dolphin вызывает окно для ввода пароля, но после ввода пароля dolphin не запускается (Хотя, раньше это таки работало.).
А у меня работает
А sudo dolphin что в консоль выдает - почему не запускается ?
ЗЫ: А зачем его пускать от рута? Что-то не могу придумать ни одного use case.
sudo dolphin
[sudo] password for ilya:QStandardPaths: XDG_RUNTIME_DIR not set, defaulting to '/tmp/runtime-root' «Session bus not found\nTo circumvent this problem try the following command (with Linux and bash)\nexport $(dbus-launch)»
ilipnitsky ★★★ ( 10.10.16 16:30:16 )
Последнее исправление: ilipnitsky 10.10.16 16:31:22 (всего исправлений: 2)
У вас он работает?
У меня работает и kdesu5 и простой sudo, что в терминале, что в Alt+F2 (только из tmux не работает).
Ты как в систему логинился? sddm?
И вооще, по «XDG_RUNTIME_DIR not set» много чего гуглится.
да, нажал ALT+F2, набрал kdesu dolphin, ввёл пароль, открылся dolphin с рутовым домашним каталогом.
Не нужно открывать Dolphin с правами администратора.
Потому что навороченые и многофункциональные GUI-приложения не являются теми, что обладают достаточной безопасностью для запуска из-под рута. Т.е. они не разрабатывались для работы из-под рута.
Это не винда, где безопасность через жопу - учись аккуратно к этому относиться.
Pavval ★★★★★ ( 10.10.16 17:40:27 )
Последнее исправление: Pavval 10.10.16 17:40:56 (всего исправлений: 1)
Потому что любой вредоносный процесс запустившийся под юзером возможно только того и ждёт, чтобы поиметь систему через XEvent. Так можно за доли секунды хоть руткит залить, а это уже серьёзно. От некоторых руткитов очень тяжело избавиться или вообще невозможно.
ну систему то всегда можно переустановить?
Хотя, спасибо за информацию, не ожидал что все так серьезно.
Alt+F2 --> kdesudo dolphin
Благодоря этой «безопасности» пользователи дестрибутивов Linux лешины не только нормального файлового менеджера но и полноценого текстового редактора . Зайдите почитайте что автор пишет это п. ц !! Какое вообще отношение имеет KWirite к библиотекам того-же Dolphin (именно на этот эксплойт годовой давности ссылаеться автор Dolphin и считает это весомой причиной рубить функционал.
Пользователи не лишены ничего. Лишены только дауны по типу тебя, мозгов. Внезапно, кдеешные либы полностью и максимально глубоко интегрированы в фм, так что тут всё логично.
I am attempting to run podman in rootless mode with lingering.
When I attempt to start the systemctl --user service podman fails with the error in the title.
In my case, I am user 1002 and the error states UID 1002, but I replaced it with 1000 as I expect that to be most common and should help with other users searching for the same error.
In my case the directory is in fact owned by the current user and is writable by the current user.
EDIT: Whenever I reboot and need to test from scratch I create a new user, so the UIDs don't necessarily match, but when applicable, they do match the user currently being utilized for testing.
Steps to reproduce the issue:
As a test, I created a new user.
sudo su - test -c 'podman info' works
So I enable linger and it fails, there is a note about this on the troubleshooting page, so let's login to the console.
On the troubleshooting page it states that I need to create a login session, so I login from the console.
I still get the error.
Ok, let's tests with the machinectl method.
Let's reboot for good measure.
sudo su - test -c 'podman info' works!
So in summary, after enabling lingering we need to reboot the server for podman to operate as that user.
Describe the results you received:
Podman does not work as a lingering user until the host is rebooted as shown above.
Command: podman info
Error: ERRO[0000] XDG_RUNTIME_DIR directory "/run/user/1006" is not owned by the current user
Describe the results you expected:
Running podman commands should work as expected after a user has been granted lingering without rebooting the host.
Additional information you deem important (e.g. issue happens only occasionally):
I am working with Ansible on this and it is repeatable for every run and every instance when the host is recreated.
I am running a Debian CT on Proxmox.
The Proxmox filesystem is ZFS so I am using the VFS driver in the CT.
Output of podman version :
Output of podman info --debug :
Package info (e.g. output of rpm -q podman or apt list podman ):
I am using the latest version of Podman available for Debian 11, I have referenced the Podman Troubleshooting Guide.
Additional environment details (AWS, VirtualBox, physical, etc.):
I'm working on a semi-embedded distribution which starts a PAM session for a designated user during boot, then instructs that session to start a target that includes Xorg and a GUI. This mostly works fine, but there seems to be a race condition in which the systemd --user run by user@.service doesn't always pick up its $XDG_RUNTIME_DIR correctly:
It seems to fail about 1/3 of the time on my virtual machine setup. I've found one possible reason for the race, which does look like a genuine bug, for which I'll send a pull request; but unfortunately, that commit doesn't actually fix it.
The text was updated successfully, but these errors were encountered:
coretemp commented Jan 19, 2018
Can you write down a sequence of such commands as I have done which you think should work without additional configuration?
It might also be that you believe that what I did shouldn't work in the first place.
coretemp commented Jan 19, 2018
This is also not the output I was looking for:
smcv commented Jun 17, 2015
But the second patch looks like a hack indeed. This really shouldn't be necessary.
I know, I deliberately didn't submit a PR for it (but we needed a workaround right now, so we can start X reliably again, and it does work).
I'm continuing to look into the root cause; the ExecStartPre is a good idea, I'll try that.
smcv commented Jun 17, 2015
One way to do it would be to turn my workaround into the real "API" used by pam-systemd: if /run/user/UID exists and is owned by UID, use it; and don't bother with /run/systemd/users/UID at all. This is unsuitable if you are more likely to change the location of users' runtime directories than to change how /run/systemd/users/UID works, though.
jtojnar commented Jan 19, 2018
It would be useful if you could share why are you trying to run the program in su .
poettering commented Jun 17, 2015
One situation where the state-file business could matter is if the way we construct XDG_RUNTIME_DIR changes, and an upgrade results in briefly running a new PAM module against XDG_RUNTIME_DIRs created by an old logind, or an old PAM module (in a long-running daemon) against XDG_RUNTIME_DIRs created by a newly restarted logind. I'd assumed that this sort of concern was why we didn't just do (API calls that end up with) the simple printf.
Yupp, that was something I thought, but back when I hacked this up I didn't realize the race you ran into. I think just accepting that upgrades are fucked is nicer in this case then adding more synchronization between the components.
coretemp commented Jan 19, 2018
Just su - without sudo also has the same result.
smcv commented Jun 17, 2015
Do you mean a stateless call that doesn't look at the filesystem, and just returns the equivalent of printf ("/run/user/" UID_FMT, uid) ? I'd assumed that if it was that simple, you'd already have done it.
I have a patch for the current way of doing it (as described in my most recent comment here) that needs some testing, but is hopefully ready. But I could go for the other approach if desired.
poettering commented Jun 17, 2015
But the second patch looks like a hack indeed. This really shouldn't be necessary.
Have you tried adding an ExecStartPre=/bin/cat /run/systemd/users/1000 to your user@.service, so that that file is logged right before the user instance is started?
coretemp commented Jan 19, 2018 •
Should the below generate the wrong ownership line or not?
I think one of the command sequences above (i.e. running systemsettings5) as root in the desktop environment shell of another user should work. Specifically, the command sequence I specified in the first message in this conversation. Thoughts?
poettering commented Jun 17, 2015
Do you mean a stateless call that doesn't look at the filesystem, and just returns the equivalent of printf ("/run/user/" UID_FMT, uid)?
I'd assumed that if it was that simple, you'd already have done it.
Well, we didn't have src/basic/login-util.c and hence no nice place to have function to share between the module and logind ;-).
jtojnar commented Jan 19, 2018 •
smcv commented Jun 17, 2015
The other way to do it would be to write out the state-file in this one particular case even if u->starting is not yet true, because it is about to be true. We shouldn't actually set u->starting to true any earlier, because that has an effect on how much we roll back when the user is finalized (we shouldn't emit UserRemoved if there was no UserNew).
jtojnar commented Jan 19, 2018
Do you want to achieve something specific? Why not just log in as the user?
Читайте также: