Skip to content
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

Remove might be a bit to harsh #8

Closed
KalleDK opened this issue Jan 7, 2021 · 3 comments
Closed

Remove might be a bit to harsh #8

KalleDK opened this issue Jan 7, 2021 · 3 comments

Comments

@KalleDK
Copy link
Contributor

KalleDK commented Jan 7, 2021

xdg/base_dirs.go

Lines 57 to 60 in aad56ae

// For security reasons, the runtime directory cannot be a symlink.
if err = os.Remove(bd.runtime); err != nil {
return "", err
}

Shouldn't this just give an error? It feels like deleting a file without "consent" is a bit harsh.

@adrg
Copy link
Owner

adrg commented Jan 7, 2021

Yes, it could return an error there. However, the runtime directory must be a directory and it must be owned by the current user according to the specifications. On that code path, the file is not a directory. The other thing the specs specify is that the user owner must be the only one with read/write access to it.

$XDG_RUNTIME_DIR defines the base directory relative to which user-specific non-essential runtime files and 
other file objects  (such as sockets, named pipes, ...) should be stored. The directory MUST be owned by the
user, and he MUST be the only one having read and write access to it. Its Unix access mode MUST be 0700.

EDIT: it's a very unlikely scenario. But yes, it probably is a bit harsh to remove it.

@KalleDK
Copy link
Contributor Author

KalleDK commented Jan 7, 2021

Correct, I agree that these are the rules, but if that path exists, and I don't have XDG path setup, a program would simply delete that file.

The way I look at it, if XDG_RUNTIME_DIR is invalid, the the user have an invalid XDG setup, if the user have an invalid setup, a program shouldn't just remove files.

Bu I do agree that an error should be returned, such that we adhere to the rules.

@adrg
Copy link
Owner

adrg commented Jan 7, 2021

Removed the directory verification. If the file is not a directory, createPath will return an error instead.
Closing this issue.

@adrg adrg closed this as completed Jan 7, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants