-
-
Notifications
You must be signed in to change notification settings - Fork 29
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Create
may set up wrong permissions for some directories in the path
#46
Comments
Hi @dinoallo. If I understand correctly, the scenario you are describing is the following:
Sure, in that case, the library would return an error specifying that it could not create that path. Also, the same error would be returned if On most systems, In my opinion, applications should treat cases where files cannot be created at a particular location. If |
Hi, @adrg, thank you so much for the speedy reply.
This correctly describes the scenario that I brought up, and for convenience, I will call the application that has root privileges
A crash may be over exaggerated in my opinion, but some applications probably set
For example, a distribution that doesn't use
I think the blame is definitely on the wrongly-configured system, but there are probably some actions to take to prevent clueless developers from messing up system directories when calling |
I'm a bit torn regarding this approach because the end result is almost the same as the current one. Let's say Scenario 1: Scenario 2: So in both scenarios, there is an error. A regular user would not be able to write a runtime file at that location. With the approach you suggested, there would still be an error saying the runtime file cannot be written at that location. The difference would be that the Now, let's say I'm setting a custom value for However, with the approach you mentioned, the directory would not be created and instead an error would be returned by Moreover, even applications running as root would not be able to write runtime files in |
What I am suggesting is maybe
Even if
If the system has custom-defined
Assume that Also I think the possible solution I mentioned earlier is still rough and needs to be more considerate. It still has room for discussion. |
This is a strong argument against creating the
But yeah, I tend to agree with you that maybe a check should be made to ensure the existence of the directory pointed to by the The spec also mentions this:
I guess that |
|
This is application logic. The library should not be responsible for naming the directory the application stores files in. Also, generating a random string would kind of go against the spec:
So when an application calls
As stated by the XDG base directory spec:
|
I am actually on the same page with returning the viable path only. It's re-usable and feels more natural.
Yea, it seems reasonable to me. |
Hi, I have noticed that it might not be correct to create all directories with
0o700
permissions:xdg/internal/pathutil/pathutil.go
Lines 52 to 54 in d31002f
To be specific, the permission of
XDG_RUNTIME_DIR
is supposed to be700
but its parent, usually/run/user/
, is not. And if above code runs in a part of system daemon and has root privileges, some services that run as normal user may crash. This issue occurs when the system doesn't previously set up/run/user/
, hence it's created alongsideapp/
.The text was updated successfully, but these errors were encountered: