@emitorino
Thanks for help.
We are not able to edit the topic now.
We will update the manifest and push the snap again. But one query here…
Should we push the snap again and get the review and approval again on the same topic or will it be a new manual review again?
The revision will be automatically rejected since the declaration have not been granted yet as per the Process for aliases, auto-connections and tracks we still need more votes.
Why does the snap need access to the real ~/.local/share/bconf? Snaps have their own private $HOME under ~/snap/mqttdesk/<revision> and so should happily work if they respect $HOME - ie. the snap should just use the path $HOME/.local/share/bconf and this should just work, then there is no need to access the user’s actual ~/.local/share/bconf directory via personal-files. @newbee_snap can you please comment?
Hello there, we’re using a third-party node.js package called Cryptlex and they told us that they need access to those folders.
Because the API we are using access the ~/.local/share/bconf and /sys/devices/virtual/dmi/id . This is all in order to prevent software piracy.
It will check the /.local because it will check the other license information availablity on the user personal files.
The licesnsing API suggested us that using classic mode will work and we tried that and it did work…
Requesting you to please provide classic mode.
This snap does not meet the requirements for classic confinement and so this is not suitable in this case.
However, as I said above, I don’t think you should even need personal-files if the code can respect $HOME, however if this is not the case then personal-files can be used for access to ~/.local/share/bconf if this is strictly necessary. Also a number of existing interfaces do provide some access to some of the paths under /sys/devices/virtual/dmi/id - can you please be more specific as to which files you require access to from this path? Finally, system-files can be used to grant this access as well.
Please can you respond to these questions and we can try and help.
Sorry for late reply.
Please give us one more day we are testing our app with the asked environment with strict confinement. We will get back shortly. But definitely we need support to get approve for the personal files access and the hardware observe or system file. which we will confirm after testing with strict confinement. Thanks for helping us.
We tried to add personal files & systems files to the snap and tried to run it locally but as attached there are 2 warnings in that we cannot use both of them. we are building the .yaml in electron.js.
Overall we are not able to add these plugs and test it locally. Even manually cannot add them. Below is the files we need access to run the app with auto connecting mode.
We found that we need classic mode to run it as it works perfectly in that mode.
We need to access to these below files but we are not successful to connect them in local too.
/etc/os-release,
/sys/devices/virtual/dmi/id/bios_vendor,
/sys/devices/virtual/dmi/id/product_serial,
/sys/devices/virtual/dmi/id/product_name,
/proc/cpuinfo,
& Personal files access for it along with the auto connect.
We request for the classic mode with the auto connect too.
Please suggest us on it./proc/cpuinfo can be read if your snap plugs the hardware-observe interface.
If you plug system-observe then the snap should be able to read the /etc/os-release file however note this is then located at the path /var/lib/snapd/hostfs/etc/os-release - so please update your snap to read from that path instead.
As for the /sys/devices/virtual/dmi/id/ files, the best option would be a system-files instead which specifies read permission for those 3 files and this could be named product-dmi-ids or similar.
Thanks for the input.
We are trying to make it happen. Just trying until it works.
Thanks again . We will come back shortly for a review.
We have tried to publish my snap through snapcraft but it shows automatically rejected and shows the errors showed in attached file. Requesting you to please suggest for the same…
it would be very helpful if you could refrain from posting screenshots of text and instead copy/paste the text so people can refer to specific lines without having to type them in manually (and painfully) off your screenshot …
this seems to be a mis-formatted plug definition in your snapcraft.yaml, could you copy/paste that part here ? normally you just have a single line for that interface like:
apps:
foo:
command: bar
plugs:
- hardware-observe
Iam extremely sorry for doing that in hurry and thanks.
This is how we defined it in yaml.
read-proc-cpuinfo:
interface: hardware-observe
read:
- /proc/cpuinfo
yeah, that will not work, just add the hardware-observe plug to your lists of plugs for the app like i have shown above, that should be enough to get you access to /proc/cpuinfo, there is no need to specify single bits you want to access for this interface …
reading of /proc/cpuinfo is allowed as part of the interface:
https://github.com/snapcore/snapd/blob/master/interfaces/builtin/hardware_observe.go#L106
(feel free to take a look at the code to see what other files it allows 
)
EDIT: note that except for personal-files and system-files interfaces you typically do not have to add anything else but the plug name to your snapcraft.yaml … i’d recommend to take a look at the other files in the above dir (which is essentially “all known interfaces”) to get an idea about them …
@newbee_snap could you please also rename this request to remove the need of classic confinement (and add the auto-connection one?)
Thanks for information.
We need only the proc/cpu info rather than the others.
But iam not sure how would we do that with electron-builder as we are creating it with jsonpackage.
It seems to be totally different than our previous one and we would like to read only /proc/cpuinfo. Please see the yaml file structure …
read-sys-devices-virtual-dmi-id-product-name:
interface: system-files
read:
- /sys/devices/virtual/dmi/id/product_name
read-proc-cpuinfo:
interface: hardware-observe
read:
- /proc/cpuinfo
name: mqttdesk
version: 2.1.0
title: MqttDesk
summary: MqttDesk
description: MqttDesk
architectures:
well, there is no choice here … you get all of them or none 
the only permitted syntax for using hardware-observe is the one i gave above … replace read-proc-cpuinfo in your plugs: section with hardware-observe and remove the read-proc-cpuinfo block at the top …
also, when pasting yaml, use three backticks ``` above and below your paste, then the indentation persists and the file stays readable …