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.
Thanks for suggestion.
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.
i think that is pretty typical for home-built PCs, try on a laptop
yeah, it’s different on a laptop, still that doesn’t make it any more useful for associating a license with a specific computer
@newbee_snap apologize about the confusion. Let me first clarify that:
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!
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!
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:
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
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.
@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?
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.
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 ```
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.
@emitorino Iam sorry for that.
Let me explain it again.
there is issue when we read & write $HOME/.local/share/data/bconf/data.conf
so we are trying to drop the dot files access for snap.
We need help into the right absolute path for HOME -plug interface where we can keep the file and read & write from that directory path. As we are trying to access the multiple different paths but getting no permission to write access errors .
Can you please suggest the right absolute path which does have write access to home -plug?
The personal-files doc have some examples about it. Did you take a look? So you should have something like:
plugs: dot-local-share-data-bconf-data-conf: interface: personal-files write: - $HOME/.local/share/data/bconf/data.conf
Otherwise, share your snapcraft declaration and we can review it.
Actually , we have succeeded in that for the dot files plug interface, but issues is that we are using one more file into same directory for licencing usage and we have to include that file too with personal-file plug interface. We have tried snappy-debug too and received the same information .
Atlast we would upload the snap in few minutes again for review.
Uploaded new version with review requested.
Iam hereby requesting review for Strict - confinement with below requesitions for interfaces.
Personal files - Auto connection/ read-write
System files - Auto connections/read
Hardware observe- Auto connections/read
Please review them.
Please review the manifest too.
Thanks in advance.
Hi @newbee_snap - so there are a couple simplifications I think you can make - for the
personal-files instance, you could just declare a single
write location of the directory as follows:
dot-local-share-data-bconf: interface: personal-files write: - $HOME/.local/share/data/bconf
Which will then allow you to write whichever files you require within this directory as in this case.
mqttdesk is not the clear owner of this path (ie there is no
mqttdesk path component here) +1 from me for use of this
personal-files instance as I have declared it above, BUT not for auto-connect of this. If instead this could be located within a path such as
~/.local/share/mqttdesk/data/bconf or similar then I think it would be appropriate for this to be auto-connected.
system-files instances, +1 from me for auto-connect and use of these paths for
Can you please update the snap yaml to make this change to combine the two personal-files instances down to a single one as above? And can other @reviewers please vote too? Thanks.
Thanks , I will change the files to directory write- personal-files interface.
Agreed on your comments.
Please find the below updated snap yaml & we have dropped the request for personal-files, so we dont need personal-files permission.
We need below interface requested for snap. Please review them .
System files & Hardware-observe- Auto connections/read
4.Hardware observe- Auto connections/read
Below is the yaml file for review…
grade: stable confinement: strict plugs: gnome-3-28-1804: interface: content target: $SNAP/gnome-platform default-provider: gnome-3-28-1804 gtk-3-themes: interface: content target: $SNAP/data-dir/themes default-provider: gtk-common-themes icon-themes: interface: content target: $SNAP/data-dir/icons default-provider: gtk-common-themes sound-themes: interface: content target: $SNAP/data-dir/sounds default-provider: gtk-common-themes read-sys-devices-virtual-dmi-id-bios-vendor: interface: system-files read: - /sys/devices/virtual/dmi/id/bios_vendor read-sys-devices-virtual-dmi-id-product-serial: interface: system-files read: - /sys/devices/virtual/dmi/id/product_serial read-sys-devices-virtual-dmi-id-product-name: interface: system-files read: - /sys/devices/virtual/dmi/id/product_name name: mqttdesk version: 2.1.0 title: MqttDesk summary: MqttDesk description: MqttDesk architectures: - amd64 apps: mqttdesk: command: command.sh plugs: - desktop - desktop-legacy - home - x11 - wayland - unity7 - browser-support - network - gsettings - audio-playback - pulseaudio - opengl - hardware-observe - read-sys-devices-virtual-dmi-id-bios-vendor - read-sys-devices-virtual-dmi-id-product-serial - read-sys-devices-virtual-dmi-id-product-name environment: DISABLE_WAYLAND: '1