aa_getpeercon() failed for process: Protocol not available #167
Comments
|
@Ziris85 hey, the Ubuntu AppArmor is quite heavily patched to support snaps. I expect there's something incompatible between libapparmor in the snap and the Debian kernel AppArmor implementation. Looking into Either way, we have the https://mir-server.io/docs/ubuntu-frame-configuration-options#heading--snap-configuration-config |
This does sound like it is differences in AppAmor between Ubuntu and Debian. We would need to understand what has changed and likely change the Frame snap to fix. There are, however, a couple of things you can try as a workaround before that happens:
More details on configuring Frame here, or the TL;DR: snap set ubuntu-frame config "
authorise-without-apparmor=true
" |
|
Hey there @Saviq @AlanGriffiths , thanks for getting back with me! I tried the I'm not sure if this is related to the OSK still not showing up or not? |
|
@Ziris85 thanks for the update. Part of the problem you describe now ("all that happens is a persistent, empty gradient box on the display (no keyboard)" sounds similar to canonical/ubuntu-frame-osk#58. Could you try the version of Ubuntu Frame that's now in testing? (I think the fix for canonical/ubuntu-frame-osk#58 is already in 2.15, but want to be sure.) The other part of the problem "clicking into text fields doesn't produce a keyboard" could be a problem with the client app (that needs to request the keyboard when you click on the text field). What app are you testing with? |
|
I've reproduced this and looking from snapd perspective. |
|
With the help of strace I got this: I had a look at what the kernel in Debian bookworm (11) says. At the time of this writing this is 6.1.0-17: This toy C program: #include <stdio.h>
#include <stdlib.h>
#include <sys/socket.h>
int main(int argc, char **argv) {
int sv[2];
if (socketpair(AF_UNIX, SOCK_STREAM, 0, sv) < 0) {
perror("socketpair");
};
char sec_buf[128];
socklen_t sec_buf_len = sizeof(sec_buf);
if (getsockopt(sv[0], SOL_SOCKET, SO_PEERSEC, sec_buf, &sec_buf_len) < 0) {
perror("getsockopt SOL_SOCKET SO_PEERSEC");
}
return 0;
}Fails as follows: Similarly strace shows: As such I don't believe this particular failure is related to snap sandbox. It seems that it is just not implemented in that particular kernel, yet. As a quick sanity check, the program works fine on Fedora 39 with 6.7.7. |
|
Looking at the kernel some more, in 6.1 this is the implementation: int security_socket_getpeersec_stream(struct socket *sock, char __user *optval,
int __user *optlen, unsigned len)
{
return call_int_hook(socket_getpeersec_stream, -ENOPROTOOPT, sock,
optval, optlen, len);
}So I suspect that unless there's an LSM hook present, the error is really EDIT: correction, I think there's something I'm missing here, the hook is present in 6.1: static int apparmor_socket_getpeersec_stream(struct socket *sock,
char __user *optval,
int __user *optlen,
unsigned int len)
{
char *name;
int slen, error = 0;
struct aa_label *label;
struct aa_label *peer;
label = begin_current_label_crit_section();
peer = sk_peer_label(sock->sk);
if (IS_ERR(peer)) {
error = PTR_ERR(peer);
goto done;
}
slen = aa_label_asxprint(&name, labels_ns(label), peer,
FLAG_SHOW_MODE | FLAG_VIEW_SUBNS |
FLAG_HIDDEN_UNCONFINED, GFP_KERNEL);
/* don't include terminating \0 in slen, it breaks some apps */
if (slen < 0) {
error = -ENOMEM;
} else {
if (slen > len) {
error = -ERANGE;
} else if (copy_to_user(optval, name, slen)) {
error = -EFAULT;
goto out;
}
if (put_user(slen, optlen))
error = -EFAULT;
out:
kfree(name);
}
done:
end_current_label_crit_section(label);
return error;
}The helper is: static struct aa_label *sk_peer_label(struct sock *sk)
{
struct aa_sk_ctx *ctx = SK_CTX(sk);
if (ctx->peer)
return ctx->peer;
return ERR_PTR(-ENOPROTOOPT);
} |
|
Still digging some more, I switched the |
|
I've suspended debugging as there's something more important I'm looking at. I cannot yet say if this is a kernel bug in Debian or just something that ought to be handled in the app. |
|
From a practical perspective, we can encounter this |
|
@Ziris85, there's a build with a potential workaround that could try with: (Or It will be sometime next week before I have time to test for myself. |
|
Hmm, what's the easiest way to test this? I have an LXC instance of debian/buster, but that doesn't replicate the problem (as I might have expected if I thought about it). |
|
Sounds plausible, but that doesn't reproduce either. |
|
OK, reproduced on bare metal. But the fix doesn't seem to work as expected. More tomorrow! |
Testing the right thing does work though. 🎉 |
|
Hi! @AlanGriffiths im not 100% sure what the fix to the issue is now. Did you find one and could you guide me to the correct settings? Thanks |
|
@tbanetwork sorry if it wasn't clear: adding |
|
@AlanGriffiths thanks for getting back to me and pointing me in the right direction. |
Hello! To begin with, I think this issue might be closely related to #77 , though in my case I'm running the latest version of Debian with apparmor in full enforcing mode, and I'm seeing a very similar, though slightly different, error:
Issue is the same as the other one, however, in that the osk snap isn't working properly. The frame (I'm using
wpe-webkit-mir-kioskhere too) is otherwise working fine, as far as I can tell. I also installed using the pretty simple steps for ubuntu-frame and ubuntu-frame-osk. Versions at play on my system:Any more info I can provide to help debug this, let me know! Thanks!
The text was updated successfully, but these errors were encountered: