Request review for auto connections for interfaces -Personal files, System files & Hardware observe for MqttDesk snap

@reviewers

Trying to get it on Snap for last 2 months and at last we have done few changes in our application.
MqttDesk is crossplatform IOT-MQTT Client app for IIOT applications.

Hereby , we are requesting to review our request and allow us to use the auto connections for
below interfaces to access the related files.

Personal files - $HOME/.local/share/data/bconf
System files -
/etc/os-release
/sys/devices/virtual/dmi/id/bios_vendor
/sys/devices/virtual/dmi/id/product_serial
/sys/devices/virtual/dmi/id/product_name

Hardware observe-
/proc/cpuinfo

We are using personal files to read and write at above location a file created by our app for licensing purpose. So we request here to auto-connect interface for personal files.

We are using system files to get the system information to match with the licensing requirements.
We are using Hardware observe for the CPU information .
so hereby we are requesting to please allow us to proceed further.

hello there
Is the requested format right or should I have to request for review again?
AS other active topic has not been closed yet I think.

@reviewers

Requesting to please look into our request.

@emitorino
Iam sorry but I am bit confused about the process.
I got rejected with a message as below and Now , I dont know where to discuss and which topic should be the course of discussion. And Please suggest me which topic is to be used to discuss and proceed.


#3

Rejected by Maria Emilia Torino. “Rejecting this revision meanwhile completing the discussion in the public forum https://forum.snapcraft.io/t/request-review-for-auto-connections-for-interfaces-personal-files-system-files-hardware-observe-for-mqttdesk-snap/25470/2” — Maria Emilia Torino ```

FYI, on my system with ASRock motherboard:

$ sudo cat /sys/devices/virtual/dmi/id/product_serial 
To Be Filled By O.E.M.
$ sudo cat /sys/devices/virtual/dmi/id/product_name 
To Be Filled By O.E.M.

I’m thinking that maybe we should extend the hardware-observe interface to cover /sys/devices/virtual/dmi/id/*, the kernel already mediates access to more sensitive information such as serial numbers.

This will most likely indicate ubuntu-core. Perhaps you really want system-observe interface to be able to access /var/lib/snapd/hostfs/etc/os-release?

1 Like

@mborzecki
Thanks for prompt reply.
I din’t understand the above system files - To be filled by O.E.M.

And for the hardware observe we need to get only /proc/cpuinfo and we had to have use the hardware-observe coz of single plug only.

We understand that system-observe is to use for that but at presently we are using /etc/os-release for the information.

We are using system files as we are using a licencing system on the app.

Thanks again

this will not help you, in the snap runtime environment /etc/os-release is coming from the base snap, not from the host, you can try it yourself by spawning a shell inside the snap environment of any snap:

ogra@anubis:~$ cat /etc/os-release 
NAME="Ubuntu"
VERSION="20.04.2 LTS (Focal Fossa)"
ID=ubuntu
ID_LIKE=debian
PRETTY_NAME="Ubuntu 20.04.2 LTS"
VERSION_ID="20.04"
HOME_URL="https://www.ubuntu.com/"
SUPPORT_URL="https://help.ubuntu.com/"
BUG_REPORT_URL="https://bugs.launchpad.net/ubuntu/"
PRIVACY_POLICY_URL="https://www.ubuntu.com/legal/terms-and-policies/privacy-policy"
VERSION_CODENAME=focal
UBUNTU_CODENAME=focal
ogra@anubis:~$ snap run --shell htop
To run a command as administrator (user "root"), use "sudo <command>".
See "man sudo_root" for details.

ogra@anubis:/home/ogra$ cat /etc/os-release
NAME="Ubuntu Core"
VERSION="20"
ID=ubuntu-core
PRETTY_NAME="Ubuntu Core 20"
VERSION_ID="20"
HOME_URL="https://snapcraft.io/"
BUG_REPORT_URL="https://bugs.launchpad.net/snappy/"
ogra@anubis:/home/ogra$ exit
ogra@anubis:~$

to see the file from the host in this case, you must use /var/lib/snapd/hostfs/etc/os-release

1 Like

This is the content of those 2 files on my system. Given that it comes directly from the motherboard vendor, I would assume it’s totally unreliable/bogus.

@ogra

Thanks for suggestion.
Understood well , we will request later on for /var/lib/snapd/hostfs/etc/os-release after upgrading our library for system-observe and we will drop /etc/os-release from present builds after review of other interfaces.

1 Like

@mborzecki

The command is different to get the system files to get the information .
"/sys/devices/virtual/dmi/id/product_serial " is a string used to read the product information for licencing purpose.May be a direct command of string wont give you actual or wrong command in terminal.

Maybe I wasn’t clear. The content of that file is literally: To Be Filled By O.E.M.. At least for that particular model of the motherboard I have in my deskto PC, the content was left in some default state.

1 Like

i think that is pretty typical for home-built PCs, try on a laptop :wink:

yeah, it’s different on a laptop, still that doesn’t make it any more useful for associating a license with a specific computer :smile:

1 Like

@newbee_snap apologize about the confusion. Let me first clarify that:

  1. This request is now falling under the Process for aliases, auto-connections and tracks. If you see there, there is a 1 week voting period (this request was created 5 days ago so we are still under the voting window). We have a queue of requests we are processing, so we are sometimes not able to process every request as it is created. Thanks for your patience!

  2. We (@reviewers) also monitor new snaps or new snaps revisions uploaded to the store and we make sure we provide an answer to publishers whenever the automated review leave a revision in a state which requires our attention. In this case, I rejected your last revision since we have this discussion in progress. We will go back to it as soon as this request is completed. If it get the enough votes, declarations will be granted on the store side, and after re-running the automated review, the revision should be approved and released. I particularly linked this topic for reference, so there is no need to create yet another topic.

Hope it is clear now!

Hey @newbee_snap,

I assume there is a file created by mqttdesk in the $HOME/.local/share/data/bconf directory, am I correct? If that’s correct, please adjust your declaration to request write access to the specific file instead of the whole directory, and if it becomes clear that the file is owned by mqttdesk, then you should be able to get the enough votes for auto-connection, otherwise you probably will get only use. Also, did you try the suggestion provided by @alexmurray in your prior post? Maybe personal-files is not even needed at all:

Regarding access to /etc/os-release, both @alexmurray in the previous post as well as @ogra here indicated:

I see your snap is still referring /etc/os-release:

read-os-release:
    interface: system-files
    read:
      - /etc/os-release 

Can you please update it to read from /var/lib/snapd/hostfs/etc/os-release? Also, please name the interface reference in a way it properly describes the file being accessed, such as hostfs-etc-os-release

Regarding hardware-observe, I still see in your snapcraft:

read-proc-cpuinfo:
    interface: hardware-observe
    read:
      - /proc/cpuinfo

Did you see what @ogra also indicated in your previous post? Request for Strict confinement to classic confinement for MqttDesk

Please make the required changes and let us know so we can proceed with the voting process.

Thanks!

@emitorino Thanks for prompt reply.
Yes we are writing and reading from a file that is created & read by our library only .
Should we declare it in yaml file too?
$HOME/.local/share/data/bconf/data.conf

And as suggested by @alexmurray is not possible for us now as we have developed this app for cross platforms and if we change the location of file to $HOME , then we have to change the individual location of file for Windows,Windows store, macOS Store, Chrome store, but yes we are thinking to update our library for future revisions to stick to the $HOME directory.

We will drop the /etc/os-release as suggested by @ogra for now as we have to update our library to access the /var/lib/snapd/hostfs/etc/os-release- may be in future revisions we will ask for review for this.

We have changed the hardware-observe as suggested and will be in manifest with new revision.

Please suggest that 'should we create new snap revision package and push to store with discussed things like hardware-observe & /etc/os-release.

Yes please. If your snap is creating and reading it, any chance the file name can contain the snap name and thus it is clear that the snap owns it?

Ok! let us know whenever that happens so we drop the granted privileges.

I am not quite sure if I am properly understanding this comment, but yes please, make the required changes and upload a new revision so we can move fw with the request.

@emitorino Thanks understood it well.

@ogra Can you please support ? As now we found an issue with the snap that when we add personal files like - $HOME/.local/share/data/bconf/data.conf"- then it wont read or write the file, but when we just remove the file name and keep - $HOME/.local/share/data/bconf - then it works fine and read and write the personal files well and snap works fine.

Hey there
Can anyone please help me out in this issue?

yaml - 
dot-local-share-bconf:
    interface: personal-files
    write:
      - $HOME/.local/share/data/bconf/data.conf ```


if we read and write directory then it works perfectly but when read and write specific file it doesnot work.

For other solution we are trying to drop personal-files interface and try to write in $HOME(non-hidden files) for the directory but it doesnot work it says that no access to write file in directory.
May we get the directory path for $HOME which has writable access  and easy accessible for users.
we have tried below...


```  $HOME/$USER/Documents/MqttDesk/share/data/bconf
     /home/$USER/Documents/MqttDesk/share/data/bconf
   /home/$USER/$SNAP/MqttDesk/share/data/bconf    ```

Hey @newbee_snap,

Can you please fix the format issues in your previous comment? Otherwise is difficult to review…

Can you please share the denials you observe? If you are not familiar with it, you can try snappy-debug which will help during troubleshoiting.