Should I have changed permissions manually?

Hello

snap noob here. Love the concept.

I’ve installed my first snap, visual studio code. i used the sudo command to install it but it wouldnt start when finished.

i saw it had permissions issue. i chowned the entire snap folder to my user and gave 747 permissions to vscode folder. i then gave 747 permissions to every thing in the /home/~me/.config folder.

this resulted in success start of vscode from terminal as user.

did i do anything bad assigning these permissions? am i undermining some security or organization purpose?

why is vscode installing itself with bad permissions?

when i tried intelliJ community ed. earlier it installed (with su) and my user account could start it no problem. i removed that snap and am using toolbox to manage intelliJ.

i appreciate any insights in helping me understand what is going on. thank you very much.

It’s hard to say what definitively went wrong with your system at this point since changes were made. vscode is a ‘classic’ snap so only traditional file permissions would be in play (ie, no snap sandboxing). I would guess that some of the files that vscode needed somehow didn’t have the correct ownership or permissions when run as your user. It’s possible that if you ran it at root, it changed/created files with root ownership such that when you ran it as non-root, it had trouble.

As for doing something bad with the permissions-- ‘747’ is not what you want your permissions to be. In general (as in, unless you share files with other users on your system with group perms), your:

  • normal, non-sensitive directories should be 755 or 775
  • normal, non-sensitive files should be 644 or 664
  • sensitive directories should be 700 (eg, ~/.config)
  • sensitive files should be 600

Of course, the software you run may setup things a bit differently. I suggest running the find command to see what has the wrong ownership and permissions are. This might be a good start:

$ find $HOME -not -uid $(id -u) -ls # files not owned by you
$ find $HOME -perm 747 -ls # files you changed to 747
$ find $HOME -perm -o+w -a -not -type l -ls # any other world-writable files that aren't symlinks

That’s a bad idea as it breaks assumptions the system makes and creates security problems since you’re handing off the ability for any user in the system to write into a directory which is used and manipulated by fundamental system tools.

I would recommend going in more detail over what specifically was executed, and how the errors looked like if any, so that someone can help you sorting vscode itself out.