loading...

Discussion on: Visual Studio Code always ask for permission to save files in Linux

Collapse
yzhernand profile image
Yozen Hernandez

I would argue your projects should never be outside of your user directory if you're actively developing them. What might I ask is the scenario in which this is actually necessary? Maybe I've just never run into it.

Collapse
rahedmir profile image
Mir Rahed Uddin Author

Yes, most of the time your project directory should be located inside the user directory. That's normal. In that case, you are not going to face any kind of sudo or permission related problem but sometimes you have to deal with those directories which do not come under the user's ownership. As an example, if you do some kind of PHP project in Linux then you have to access the htdocs folder which is located in /opt/lampp/ , and this location directly not comes under any user's ownership. In this situation, if you open any file/directory which is located inside htdocs, from the VS Code then, you will get exactly the same problem that I am talking about in this article.

And people had already faced this problem way before than me. See this Stackoverflow discussion thread
stackoverflow.com/questions/510042...

Collapse
metruzanca profile image
Samuele Zanca

Your problem here is a lack of a CI/CD pipeline.
You should be editing these files somewhere locally, not directly on the server you're using. When on local you can setup your environment within your userspace, then commit and have your pipeline make the changes.

I can see how this might not be easy first time around, but I would stress that its an important thing to learn.

If you must edit a single file, and you're on linux. Why not just sudo nano file.ext? Generally won't be spending a lot of time in config files, so you don't need a full code editor.

Thread Thread
rahedmir profile image
Mir Rahed Uddin Author

I know I can do it locally, This article is not about whether I can do it locally or on a server. This article more about how you can tackle this problem for a specific text/code editor. And, here in our case which is VS Code editor. (As I mentioned in the article's title)

Thread Thread
metruzanca profile image
Samuele Zanca

There's two ways to solve a problem:

  1. Solve the problem
  2. Figure out why the problem occurred and see if it can be avoided.

In this case, the problem can be easily avoided and usually is as when you're on a server you're also likely ssh-ed into it and off chance you're using vscode-ssh you'll likely know how to sudo vscode.

I don't care what the original topic was, this got brought up (by you) and I shared my thoughts on it.

Collapse
justinhodev profile image
Justin Ho

Hey Mir,

Just a quick clarification that Apache technically allows you to serve files from any directory so you do not need to always use /opt/lampp/.

The key you are looking for in the site configuration file is DocumentRoot "/path/", after which the system administrator can enable that site with Apache.

This has been answered on StackOverflow and here's Apache docs.

Thread Thread
rahedmir profile image
Collapse
yzhernand profile image
Yozen Hernandez

I see. Well in that case I think that the problem that you and the questioner on SO have is that you're trying to fight the way the system works a bit. Directories outside of your home have permissions set the way they are for a reason.

I probably don't have to explain it to you, but for others who find this: there are potential security issues with, for example, giving some directory or file full user/group/other permissions (777) because that could grant far more access to a service than it might need (and if there's the potential for executing malicious code, it might be able to do serious damage). If you're running or developing some service, you might want to isolate the sort of damage it might do by creating a new user just for that service, and the directory with all of its files will be owned by that user.

In fact, the answer I like best on that post is this one: stackoverflow.com/a/61939446/876844. In that answer, the solution is simply to add your own user to a group which already has access to the directory. So, if the directory in question had read/write access for the www-data group (common for most web services), just add your user to that group, log out/log in, and work as usual.

In the past I've used a few other alternatives, including using a symbolic link in the outside directory which pointed to the project directory in my home dir, or a slightly more complicated setup where I used git on both sides. In the latter case, I would develop on a local directory, test things as needed, and then commit. When I had something that I felt could go out to the privileged directory, I would switch to a user that had write access there and do a git pull.

I'm not saying either solution is perfect (and maybe other users have better suggestions), but neither of these involve messing with the permissions in a directory like /opt or /var/www in a potentially dangerous manner.

Edit: formatting, spelling.

Thread Thread
rahedmir profile image
Mir Rahed Uddin Author

Well, this is also a helpful explanation indeed. Thank you