IssueTracker

AFAIK, adb server doesn't run as root unless someone manually runs as root.  "adb root" affects the adbd on the target, which writes data elsewhere.

We should still prevent this by only opening the log file in a folder that is write restricted to the current user.

This does not look like an issue.

ADB should not be required to run as root in a system that has been properly set up.

The recommended directory for user logs should be /tmp or an equivalent OS-managed directory for temporary files. Permissions are fixed by the system (+rwx all) and contents get purged by default on reboot ---> no maintenance ---> no surprises.

[Comment deleted]

Any hardcoded /tmp file write allows any user on the system to write to any file with the permission of the user doing the write. Many people run adb as root to work around USB permission issues, but even those who don't can trigger file overwrite attacks.

> The recommended directory for user logs should be /tmp or an equivalent OS-managed directory for temporary files. Permissions are fixed by the system (+rwx all) and contents get purged by default on reboot ---> no maintenance ---> no surprises.

That's not how many popular Unixlike systems are configured. /tmp is global, not per-user, and is not automatically purged on reboot (which would be irrelevant for this bug anyway).

We are having ADB issues with hardcoded  /tmp/adb.log when running AS in a lab of CS2 students. When adb.log of a previous user was not deleted, the next user to use the same machine would not be able to run ADB at all.

[Comment deleted]

As a workaround: you can use `nohup adb server nodaemon &>~/adb.log &` to explicitly start server with your own log file before actually using ADB. You can also specify your unique port via `-P` to avoid conflicts between users.

I'm not sure, though, how several ADB instances would work with devices or emulators — I encountered errors in such scenario, but at least this allows a user to use ADB if the default log file is write-protected.