I read that issue and either this is not the same case, or Steam does not iterate /etc/fstab, but partitions some other way, because /keybase is not listed in /etc/fstab. Maybe /proc/mounts is iterared?

Either way this is really problematic because it could spin up sleeping disks, connect network shares etc.

Steam should definitely only access paths with libraries on them.

I'm experiencing the same issue on installation, definitely not happy with steam trying to write anything in shared spaces.

/proc/mounts is indeed iterated - what does your /keybase mount look like in /proc/mounts ?

@TTimo:

$ grep keybase /proc/mounts 
keybase-redirector /keybase fuse ro,nosuid,nodev,relatime,user_id=0,group_id=0,allow_other 0 0
/dev/fuse /run/user/1000/keybase/kbfs fuse rw,nosuid,nodev,relatime,user_id=1000,group_id=1000 0 0

For what purpose are all partitions on /proc/mounts being written on? What is being tested?

The Steam client is looking for mount points where it could create Steam libraries (e.g. writable, can set execution permissions etc.).

In particular, it does this when you install a game in order to offer the option to create a new library on the fly for the install: https://gyazo.com/5d64b61e6e808a880b14c533ecb963e0

This feature has been in Steam for a long time (years) as far as I can tell. It's likely some users - like you - would prefer not having this and not doing full mount point scans when installing a game. The client would still need to do this when explicitly creating a new Steam library.

Trying to be "smart" and skip fuse filesystems by default (plus networked filesystems in the case of https://github.com/ValveSoftware/steam-for-linux/issues/8026) might be a problem for other users though.

Thanks for the details. I'm not going to argue for removal of that feature, as it is convenient. Issues like this are perfect for seeing if the Linux community can come up with improvements, because this seems like a generic problem.

Can you share the relevant source code / syscalls done for getting a list of installable mount points? I could look at strace, but I'm feeling a bit lazy.

Since you are looking for rw and exec partitions, /proc/mounts could be first filtered based on those flags, eg. similar to:

egrep -v '\<(ro|noexec)\>' /proc/mounts

This should weed out obvious non-candidates, like fancy configurations with ro /usr or noexec /home.

Then you still have plain directory ownership, permissions and ACLs to worry about. This would weed out some of those cases:

test -w /mount/point && echo $?

This covers the case of /run/user/1000/keybase/kbfs, which is the one causing the Keybase notification. For the sake of completeness, here are the permissions:

$ namei -l  /run/user/1000/keybase/kbfs |sed "s/$USER/user/g"
f: /run/user/1000/keybase/kbfs
drwxr-xr-x root root /
drwxr-xr-x root root run
drwxr-xr-x root root user
drwx------ USER USER 1000
drwxr-xr-x USER USER keybase
dr-x------ root root kbfs

Now, I'm not sure if these checks still miss some cases, but if unsure, the final check could stay as it currently is.

Actually writing on the disk would likely still spin up disks and possibly cause delay with network shares, but it would fix at least some cases.

If you strace test -w, you can see that it's using the access(2) function to test for access.

The mode specifies the accessibility check(s) to be performed, and is either the value F_OK, or a mask consisting of the bitwise OR of one or more of R_OK, W_OK, and X_OK. F_OK tests for the existence of the file. R_OK, W_OK, and X_OK test whether the file exists and grants read, write, and execute permissions, respectively.

I guess this syscall only needs the filesystem's root directory inode, which is very likely to be cached. Not sure how it plays with the SystemD automount case (#8026).

Just found this while looking up the same error. I was surprised Steam was trying to write to filesystems outside those already set up as Libraries.

I would personally not mind at all if the just-in-time Library creation feature could be disabled in settings. This would address #8026 as well.

one more to stumbling upon this error by Googling the You do not have write access to /keybase/.steam_exec_test.sh error message. Sad to see it's been around for so long and no solution or even a workaround to it =(

Like many others, I also stumbled upon this, and several other threads after getting a notification about keybase, and seeing stdout from launching steam from my term.

It was pretty apparent what this behavior was, but I appreciate that @kisak-valve had verified in several of the other closed issues what this was executing.

I captured the script (inotifywait -m -e create --format '%w%f' /some/writable/path | while read new_file; do cat $new_file; done), and saw that it's contents was just:

#!/bin/sh
exit 0

Simple, gets the job done, has been working for years, and.. I mean.. does that script look like it could do any harm? I get all of that.. but I think that the concern that this causes for users makes re-examining this worthwhile.

I personally do not want any application to attempt to write, and execute a bash script to every entry in /proc/mounts.

That solution:

• feels a bit greedy, and somewhat oversteps the boundary of trust that a user should have with an app, when they are being mindful of maintaining a secure, and stable system
• makes me anxious, because god knows what kind of haunted state I have my system in
  • I legitimately have 175 volumes mounted on one of my servers where I run Steam
  • I also run a headless Steam in a docker container on another server
  • I also have winesapOS that I run from a bootable live NVMe (where adding an additional storage path isn't currently working, and now I might know why)

On the developer side of things, I've written plenty of install scripts, and I've learned to be mindful of what seems like polite etiquette in terms of what is executed on a user's system.

What I'm rambling about here, though, is to ask:
If this were an unsolved problem today, how would you go about solving it? I'd like to think this would be handled in a more elegant way. Probably not with a bash script.. but even within the realm of keeping it to just a dumb bash script, maybe it could be as simple as

#!/usr/bin/env bash

checkMount() {
    [[ -w $1 && -d $1 && -x $1 ]] && echo "$1"
}

export -f checkMount

awk '{print $2}' /proc/mounts | \
    grep -v '^/boot\|^/dev\|^/proc\|^/run\|^/sys' | \
    xargs -I{} bash -c 'checkMount "{}"'

The output of this would provide parity with the current check, without actually attempting to write and execute anything.

Something like this would at least keep the paranoid folks from continually opening GH issues about it :wink:

(Sorry, adderall kicked in, and I guess I wanted to write)

Replying to https://github.com/ValveSoftware/steam-for-linux/issues/8081#issuecomment-1780318524

I'm reviving this thread because this issue still exists. I think @wallentx provided some good code for checking mount points that would solve my problem and likely others'.