#1

I’m trying to run Buildah as an unprivileged user which requires the directory /var/run/user/. I can create the directory but must do so after every reboot. I don’t see a bug report for this so it seems this is intended.

This makes me wonder if we’re really not intended to be non-root on Silverblue and it’s expected that we create regular users only within containers such as fedora-toolbox. Could someone please clarify this for me?

BTW: I just noticed this forum is within the Desktop category. I’m on SilverBlue server version but it seems there’s no option to delete my topic.

#2

My recollection is that the intent is for non-root users to be able to create images / containers with buildah / podman at some time in the future, but it’s not there yet. And no, you do not want to log in to a GNOME workstation as root - drop to the command line / console window with CTL-ALT-F3 or its ilk if you need root access and can’t get a terminal / sudo.

#3

To be clear, you’re saying that /var/run/user/$UUID doesn’t exist inside the container by default? Honestly that seems more like an oversight to me… Is this on podman’s unprivileged containers? They’re still rather new and have a few loose ends like this.

#4

This actually works already, notwithstanding a few occasional bugs (none have been deal breakers).

#5

The user run directory is not created on the host.

However, I figured out what’s going on. If login with my unprivileged user the directory is auto-created. If I login with ‘su -l’ it isn’t and no Systemd user session is created:

#su -l <user>
systemctl --user status
Failed to connect to bus: No such file or directory

Some Googling indicates this is controlled by configuration in /etc/pam.d.

#cat /etc/pam.d/su-l 
#%PAM-1.0
auth            include         su
account         include         su
password        include         su
session         optional        pam_keyinit.so force revoke
session         include         su

I’m not familiar with these settings but it appears su -l should start a user session.

In any case, now that I know to login directly I’m happy.

#6

Ah, yeah, su doesn’t start actual sessions. If you want that, there’s machinectl login .host. That being said, IIRC there are some SELinux policy issues with some of the machinectl commands, so if you run into permission errors, you can either disable it or find and apply the SELinux policies manually.

1 Like
#7

Thanks, good tip.

You recalled correctly: SELinux blocks machinectl login but at least I now know the correct command to start a session as a new user.