Investigating the reason behind "Permission denied when reading from process 2132183" #323
Comments
|
Thanks. It's helpful to know that the maps file isn't accessible. I think investigating capabilities (like In my shell, cap_ptrace is present (in the middle of the "Bounding set" list): And if I explicitly drop the capability (Note to self -- we should improve that error message so that it covers this scenario.) So, maybe your system is configured to drop For comparison, here's mine (default package-provided file from Ubuntu 20.10): |
|
Interesting, if I do My capabilities.conf file seems similar to yours: > cat /etc/security/capability.conf
#
# /etc/security/capability.conf
#
# this is a sample capability file (to be used in conjunction with
# the pam_cap.so module)
#
# In order to use this module, it must have been linked with libcap
# and thus you'll know about Linux's capability support.
# [If you don't know about libcap, the sources for it are here:
#
# http://www.kernel.org/pub/linux/libs/security/linux-privs/
#
# .]
#
# Here are some sample lines (remove the preceding '#' if you want to
# use them
## user 'morgan' gets the CAP_SETFCAP inheritable capability (commented out!)
#cap_setfcap morgan
## user 'luser' inherits the CAP_DAC_OVERRIDE capability (commented out!)
#cap_dac_override luser
## 'everyone else' gets no inheritable capabilities (restrictive config)
none *
## if there is no '*' entry, all users not explicitly mentioned will
## get all available capabilities. This is a permissive default, and
## possibly not what you want... On first reading, you might think this
## is a security problem waiting to happen, but it defaults to not being
## so in this sample file! Further, by 'get', we mean 'get in their inheritable
## set'. That is, if you look at a random process, even one run by root,
## you will see it has no inheritable capabilities (by default):
##
## $ /sbin/capsh --decode=$(grep CapInh /proc/1/status|awk '{print $2}')
## 0000000000000000=
##
## The pam_cap module simply alters the value of this capability
## set. Including the 'none *' forces use of this module with an
## unspecified user to have their inheritable set forced to zero.
##
## Omitting the line will cause the inheritable set to be unmodified
## from what the parent process had (which is generally 0 unless the
## invoking user was bestowed with some inheritable capabilities by a
## previous invocation).I read more about capabilities (in https://blog.container-solutions.com/linux-capabilities-in-practice notably) As the article explains, the Permitted and Effective set are empty here (for user) whereas it's usually full for root. This means (if I understand correctly) that the process won't get any capabilities by default unless explicitly set for the binary. Which is obviously not the case by default right after compiling: > getcap ./target/debug/rbspy
>If I give the capability to the binary (with the "effective" flag because it seems rbspy does not set the capability as effective when it's just permitted), it works: > sudo setcap 'cap_sys_ptrace+ep' ./target/debug/rbspy
> getcap ./target/debug/rbspy
./target/debug/rbspy cap_sys_ptrace=ep
> ./target/debug/rbspy record -- ruby ci/ruby-programs/recurse-sleep.rb
# works normally(This might be a good workaround for people even if we can't figure out the deeper issue) So in your case, do you have all capabilities in effective set already from bash? I tried to dig a bit about what other global configuration could yield to a different result from you VM but couldn't find it for the moment. I tried on a couple others Ubuntu (e.g. 18.04 server) and I also see: BUT in this one I can use I'm simplified my testing line to: And as we can see here there's actually no capabilities in "Effective" or "Permitted", yet it still manages to run and snapshot the ruby process. I'm confused 🤔 |
No, they're pretty similar to yours: Another possibly-interesting difference is that I can't get capabilities for files because my kernel doesn't support extended attributes for ext4: Is that also true on your server?
Nice. Yeah, I'm glad that we have a fairly simple workaround. |
|
Mmm interesting but no it's not the case on my server (I'm also on > getcap rbspy
> cat /boot/config-$(uname -r) | grep FS_XATTR
CONFIG_REISERFS_FS_XATTR=y
CONFIG_F2FS_FS_XATTR=y
CONFIG_TMPFS_XATTR=y
CONFIG_JFFS2_FS_XATTR=y
CONFIG_SQUASHFS_XATTR=y
CONFIG_AUFS_XATTR=y
CONFIG_CIFS_XATTR=y🤔 |
|
The Yama security module was mentioned on another thread this week and might be relevant. I don't know whether/how it interacts with file capabilities.
If I set it to 3 in my VM, I can repro the same permissions error that we've been troubleshooting: It defaults to 1, which allows rbspy to work normally: |
|
Nice finding! I just had a look but unfortunately I so have value 1 for both machines here (the one where it's working and the one where it's not): |
When I try to simply record a small ruby program started by rbspy it fails with the following error message
We started investigating this in #268 and moved to a new issue now that the error message is more precise.
OS:
To already answer the last comment from @acj:
Indeed I cannot:
I'm not sure why as the permission set is
444, the parent folder (pid folder) is555(and owned by the user)But I suppose the meta files in /proc do not behave like the rest ^^
People here https://groups.google.com/g/comp.os.linux.development.system/c/RAPRvAocEtU seems to say you need some "ptrace" capability. Here it says ptrace is only possible on child process in Ubuntu 10.10+: https://en.wikipedia.org/wiki/Ptrace but this is the case when I start the ruby process through rbspy I suppose? I understand I can't attach to any process as a normal user but in this case it should be possible.
The text was updated successfully, but these errors were encountered: