This patch changes SocketAddress class to create an address structure for
a pathname socket (on all platforms), provide correct length of the structure
by including length of any additional implementation specific fields
and return nullptr upon address query if the address structure was not
properly initialized.
Details
- Reviewers
dfaure ossi - Group Reviewers
Frameworks
Diff Detail
- Repository
- R241 KIO
- Branch
- master
- Lint
No Linters Available - Unit
No Unit Test Coverage
src/ioslaves/file/fdreceiver.h | ||
---|---|---|
47 | why are you moving the member? | |
src/ioslaves/file/sharefd_p.h | ||
54 | space on wrong side of amp | |
60 ↗ | (On Diff #26443) | you're removing that without replacement. that makes me think that the patch is still non-atomic. |
71 | put spaces around binary operators | |
72 | using strncpy() after an explicit length check is relatively pointless (unless the trailing zero padding is important). |
Added space on correct side of & and on either sides of binary operators.
Used memcpy.
Restored original position of data member.
src/ioslaves/file/sharefd_p.h | ||
---|---|---|
60 ↗ | (On Diff #26443) | I just feel like the job of SocketAddress should be to create the address structure and not perform any file operation. Removal of the socket file should be handled by file ioslave or FdReceiver. |
src/ioslaves/file/sharefd_p.h | ||
---|---|---|
60 ↗ | (On Diff #26443) | that's a valid concern, but doing that belongs into a separate patch which does the complementary change (as far as necessary) atomically, and explains it properly in the commit message. |
src/ioslaves/file/kauth/fdsender.cpp | ||
---|---|---|
27 | this actually constructs a qbytearray. that should be probably explicit. a better approach would be moving the class' interface to qbytearray (or actually qstring) as well, to unify the API. but that's again a separate refactoring. | |
src/ioslaves/file/sharefd_p.h | ||
55 ↗ | (On Diff #26443) | you're removing the auto-prefixing with /tmp/. if that is intentional, you need to atomically adjust the callers, as otherwise you're changing behavior. |
56 ↗ | (On Diff #26443) | i now noticed that you removed that branch, thus removing the use of linux' abstract address space. that also calls for a justification. |
Check for null byte at index 1 in case of returning address length on linux.
Use size of finalPath as pathSize.
src/ioslaves/file/sharefd_p.h | ||
---|---|---|
61 ↗ | (On Diff #26441) | you now have a buffer overflow on linux. you need to split the conditional. |
Looks good.
src/ioslaves/file/kauth/fdsender.cpp | ||
---|---|---|
24 ↗ | (On Diff #26441) | The problem here is the API. Why is it using std::string in the first place? |
src/ioslaves/file/kauth/fdsender.cpp | ||
---|---|---|
24 ↗ | (On Diff #26441) | The idea was to use std c++ and avoid qt throughout the class because the code will be executed with elevated privileges. |
That doesn't make sense. There's QFile::encodeName in the code.
Is there a section of the library that is used in elevated privilege code, but not all of it?
src/ioslaves/file/kauth/fdsender.cpp | ||
---|---|---|
24 ↗ | (On Diff #26441) | In that case I don't understand why SocketAddress takes a QByteArray and not a std::string.... Because ossi suggested it to unify the API and avoid one conversion to std::string in fdereceiver? But then we have two contradictory goals, we need to decide whether we use Qt or not in fdsender and therefore in SocketAddress. Since one is not supposed to use Qt API without a QCoreApplication instance, and since it's not recommented to run Qt code as root, I think your original idea made sense, no Qt in fdsender nor in SocketAddress. |
src/ioslaves/file/kauth/fdsender.cpp | ||
---|---|---|
24 ↗ | (On Diff #26441) | i can get behind the idea of keeping SocketAddress and FdSender qt-free. it's ugly that FdReceiver stands out, but it would be way harder to make that one qt-free due to its use of the event loop. |