[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Where to report: root fails to edit other users file in sticky bit directory

Your right /tmp is not a tmpfs by default on Debian. I though it was, maybe being too much used to it as this is configured by default on our images. /dev/shm or /run would work better then, although /run IMO is more aimed for non-temporary files, relevant through the whole runtime of the related process or system, while /tmp is more aimed for short-term temporary files. However it was/is not my choice to use /tmp in the particular case and out of my control.

Background, if interested:
In my particular case where I ran into the issue, it is a 3rd party software that chooses to store information to /tmp/<something> via sub process which is then read by originating process. Indeed the circumstance is a bid special, the solution is even commented as an "ugly" one within the code, but no better method had been found until now. The software collects information about the Python environment by doing a dummy module install (that is aimed to fail). The dummy modules installer collects info about where it was installed to (venv/user-level/system-level, ...) and writes that to /tmp/<something> to be read by the originating Python script. It has an internal updater which invokes pip the "correct" way based on the /tmp/<something> content (e.g. --user flag or not).

I want the software to run as system service with an own limited user, but aim to have it installed as global/system Python module to /usr/local/lib|bin instead of in --user mode into its own UNIX user home directory, or as vnev, to prevent doubled Python module installs (target is small embedded systems with potentially limited disk space), easier access/maintenance for the real (login) user and clear separation between data/config and the Python modules. To retain the functionality of the internal updater, it requires specifically limited "sudo pip install <itself+dummy>" permissions to self-upgrade and do it's Python environment collection dummy install that is out of my control. The problem is now that it pre-creates /tmp/<something> as its limited service user but since pip is called via sudo, the dummy installer then tries and fails to write to that file as root user.

I am actually sort of Linux distributor, more precisely developing Debian-based images mostly for ARM SBCs together with a tool set to easily install and configure system a bunch of software titles. See the domain of my mail address. If I was a system administrator only, of course, why should I feel forced to follow any standard, but as a software developer I clearly disagree with you! The FHS is exactly what software developers should then be able to count on and respect themselves (to allow others count on it), which directories are present and used in the same (at least similar) way by the distributions own software packages as well as most 3rd party software installers. Without FHS one would quickly have all sorts of files messed across a bunch of different directory structures and sub structures, making it impossible for admins to follow any logic to find certain types of files, like software and system configuration files, variable data, temporary files etc, also to know where files are expected to survive a reboot and where not (potentially tmpfs) etc. Without FHS (or any other standard across Linux/UNIX systems) we had a mess, so FHS is no "crap" but very valuable and important, IMO.

But that is a discussion that has nothing to do with the originating issue, which has been identified thanks to your help! :) It's now a bid others and whether the default has actually been changed intentionally, and if so more like "why not" or if there have been actual concerns, serious enough to change a default, which implies different and probably unexpected behaviour. And if so, if there is a plan to have this documented a bid wider.

Best regards and stay healthy,


Reply to: