[Nut-upsuser] New User Questions - With Belkin USB

David White whitedavidp at yahoo.com
Tue Jul 16 15:09:15 BST 2019


You are a genius! Don't know why I didn't google "socket permission 
denied" before reading this response. But I did it just now and found 
this post 
which was right on target. I did a "groups nut" and discovered that the 
nut user was not in the group aid_inet (and saw that the root user was a 
member) which is required for socket access. So I added nut to that 
group and fired up upsmon in debug mode. I can not see both server and 
client sides of the socket using "netstat | grep nut". Not sure if the 
problem was client or server side without this (seems likely both, I 
guess) but no more problems! This even survives a system restart. So I 
think I am good to move on. Thanks so much for everyone's time and 
effort in helping me. I can now start pulling the UPS plug out of the 
wall and see what happens!


On 7/15/2019 8:04 PM, Charles Lepple wrote:
> On Jul 15, 2019, at 11:15 AM, David White wrote:
>> 2. When I check the results from "netstat -t -n" I am NOT finding anything on 3493. Hmmm. I then tried "netstat -l" since there should be a server socket listening on 3494, right? There is nothing of 3493. But I do see an entry with local address = localhost:nut. When I "cat /etc/services" I find nut listed on 3493.
> Mistake on my end; I was thinking "netstat -tln" or "netstat -atn". Without the "-n", it looks up "3493" in /etc/services, as you mentioned.
>> 3. So I run "netstat -l | grep nut" and I see the socket and I see an entry for what looks like a stream listener tied to /var/run/nut/blazer_usb-belkinusb.
> This should be there, but it's the Unix-domain socket (not TCP) between the driver and upsd, so not relevant at the moment.
>> 4. I did not know of the -DD option on upsmon and likely would not have thought of this anyhow. In the output I almost immediately see a connection failure to belkinusb at localhost for the socket saying permission denied. That doesn't look right. But not exactly what that means or how to fix it.
> I am still confused as to why upsc works, but maybe this is related?
> "Android adds a "paranoid network" option to the Linux kernel, which restricts
> access to some networking features depending on the group of the calling
> process. This option should not be set in any other OS not using Android
> security model - because it requires 4 groups with specific UIDs (3001-3005)
> to exist, and all relevant users to be added to them - which in our case would
> be all users anyways, as that's the "traditional" behavior."
> https://github.com/AsteroidOS/meta-bass-hybris/commit/b819096ed5a5ef12828c63b1f2f0b8e962fd1e81
> More info:
>  * https://wiki.postmarketos.org/wiki/Kernel_configuration#CONFIG_ANDROID_PARANOID_NETWORK
>  * https://elinux.org/Android_Security#Paranoid_network-ing
> If you can get to the kernel config for the Android side of things, you can check for that CONFIG_... option. If it is enabled, then maybe there is something different about the user ID that upsmon is running under versus upsc.

More information about the Nut-upsuser mailing list