tnx Ikke, I am always in favor of simple and efficient
As a matter of fact that is also how the DS18B20 is read on the raspberry, but as it requires file writes for every reading, I try to stay away from that. Nevertheless, it is an interesting addition.
As for accuracy of the DHT11… I have a couple of “old” ones and compared to some new ones I had bought, they have about a 5 degrees difference (Celsius).
I will all phase them out
/proc isn’t on the SD card so reading and writing to it won’t impact the longevity of the SD card. Everything in Linux is a file and everything in /proc is where the “files” that represent the running processes on your system go.
So unless I’m missing something, you can read and write to the device using the file in proc all day and it won’t be problem.
good to know. Tnx.that helped a lot!!!
I thought the values were stored in ‘sys’
thanks for that link.
learn something new every day
For completeness, /dev is the same as /proc only that file system represents the hardware in your machine.
Thank you Rich
Most examples I saw for reading the DS18B20 though are writing in the ‘/sys’
hence that I thought they were ‘genuine’ file writes. As in ’ writing to SD’
But that one indeed seems pretty ’ virtual’ as well.
Still lots to learn I guess
Absolutely brilliant works like a charm thank you so much for this tutorial just kept it as a DHT22
No, when it comes to writing privileges for the world on programs, it doesn’t. Especially when it is about suggesting that to others. Then it is “never, ever” have world write rights.
And if you want to edit the file from other accounts, you should use groups.
It is personal preferences to use octal or symbolic file rights though. I do prefer the logical symbolical, as it can add or remove just the privileges that are relevant. With octal you need to change all (like the = operator in symbolical rights)
The py-file being writeable by world could be the way into your system.
When replying, especially to a long dormant thread, please quote a little bit of what you are replying to.
That’s a pretty absolute statement. I find that absolute statements particularly in computer security, are suspect.
In this case I assume that it is because of the 0777 on the Python file in the OP.
So what does giving works rwx rights on this Python file do? It means that any user on that machine can open, change, and run that file. It does not mean that the program itself suddenly gets permission to write to all files on the OS(that would only be the case if the root user ran the program which would be a significant vulnerability that someone could use to get in to your system).
That doesn’t sound like a good thing, but wait, an attacker would already have to be on the machine already to exploit that file. And even if they did exploit the file, they can only make the program do things the user that program runs under has permission to do. That’s why we don’t run services as root.
Now a lot of damage can be done by having a services’ program editible by all. But, like I said, the attacker would have to already be on your system. Making the Python file’s permissions more restrictive would not prevent an attacker from getting on your system.
Given this is a single user computer on a network that is not exposed to the internet, your network and this computer has to essentially be pwned befire they can even get at this file.
Is it a best practice to ashtrays use the most restrictive sets of permissions in a DAC system? Yes. Will setting the permissions do anything to protect the computer from being hacked? No. In most home network use cases, it really doesn’t matter.