"Failed to create secure directory" when .pulse is a symlink

[elitak]

I'm on debian x64 using package version 0.9.15-4.1.

I have .pulse as a symlink to local/.pulse (a dir) in my home directory. 'local' is a symlink to /some/abs/path.

When I try to run gnome-volume-control.pulse I get "Failed to create secure directory" and the process just hangs with no GUI elements popping up.

Only by doing an strace did I discover what the problem was. The log of stdout/err is attached. Search for "secure" to find the relevant spot.

[elitak]

stdout+err dump of "strace gnome-volume-control"

[lennart]

Yes, we verify that we place our security-relevant information in a directory with the right permissions and that noone plays games with us. This is intended behaviour, not a bug.

[elitak]

Whether it's the correct behavior or not, this is a big concern for usability.

If launched from a gnome desktop shortcut, the app gives no indication that there's a problem and doesn't even terminate. There should at least be a dialog box that the user must dismiss. Flag this ticket as an enchancement or retitle it, perhaps?

Also, I don't understand how disallowing intermediate links to the .pulse directory makes anything more secure, but then I certainly don't have anything close to the whole picture. I'll just have to take your word on it, unless you'd care to explain?

[lennart]

Replying to elitak:

Whether it's the correct behavior or not, this is a big concern for usability.

Usability? What does ~/.pulse have to do with usability?

If launched from a gnome desktop shortcut, the app gives no indication that there's a problem and doesn't even terminate. There should at least be a dialog box that the user must dismiss. Flag this ticket as an enchancement or retitle it, perhaps?

Uh. PA is a session service, it should be run from the XDG autostart dir, not via some desktop shortcut. It should generally be invisible to the user. Also, what does that have to do with ~/.pulse not being allowed to be a symlink?

Also, I don't understand how disallowing intermediate links to the .pulse directory makes anything more secure, but then I certainly don't have anything close to the whole picture. I'll just have to take your word on it, unless you'd care to explain?

If you have a chain of symlinks and only verify the access mode of the final destination but some evildoer has write access to the dir one of the intermediate symlinks is located in he might redirect replace that symlink to some spot that is not safe. If we'd go and verify each step of the symlink chain we could detect that, however that would be very ugly and -- what's worse -- racy, since we cannot atomically check the whole chain. So, to fix this we simply make sure .pulse is not a symlink in the first place.

Also, I cannot see at all why you'd want to make .pulse a symlink in the first place.