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

From	MichaIng <micha@dietpi.com>
Newsgroups	linux.debian.user
Subject	Re: Where to report: root fails to edit other users file in sticky bit directory
Date	2020-12-09 17:40 +0100
Message-ID	<BkaFs-4YR-9@gated-at.bofh.it> (permalink)
References	<BjXRT-5j1-1@gated-at.bofh.it>
Organization	linux.* mail to news gateway

Show all headers | View raw

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,

Micha

Thread

Where to report: root fails to edit other users file in sticky bit  directory MichaIng <micha@dietpi.com> - 2020-12-04 15:00 +0100
  Re: Where to report: root fails to edit other users file in sticky  bit directory <tomas@tuxteam.de> - 2020-12-04 15:20 +0100
  Re: Where to report: root fails to edit other users file in sticky  bit directory Greg Wooledge <wooledg@eeg.ccf.org> - 2020-12-04 16:10 +0100
  Re: Where to report: root fails to edit other users file in sticky  bit directory MichaIng <micha@dietpi.com> - 2020-12-08 16:00 +0100
    Re: Where to report: root fails to edit other users file in sticky  bit directory Greg Wooledge <wooledg@eeg.ccf.org> - 2020-12-08 16:20 +0100
      Re: Where to report: root fails to edit other users file in sticky  bit directory MichaIng <micha@dietpi.com> - 2020-12-08 16:50 +0100
        Re: Where to report: root fails to edit other users file in sticky  bit directory Andrei POPESCU <andreimpopescu@gmail.com> - 2020-12-09 10:30 +0100
    Re: Where to report: root fails to edit other users file in sticky  bit directory <tomas@tuxteam.de> - 2020-12-08 17:00 +0100
      Re: Where to report: root fails to edit other users file in sticky  bit directory MichaIng <micha@dietpi.com> - 2020-12-08 17:10 +0100
        Re: Where to report: root fails to edit other users file in sticky  bit directory <tomas@tuxteam.de> - 2020-12-08 17:50 +0100
          Re: Where to report: root fails to edit other users file in sticky  bit directory MichaIng <micha@dietpi.com> - 2020-12-08 18:10 +0100
            Re: Where to report: root fails to edit other users file in sticky  bit directory <tomas@tuxteam.de> - 2020-12-08 18:50 +0100
              Re: Where to report: root fails to edit other users file in sticky  bit directory Greg Wooledge <wooledg@eeg.ccf.org> - 2020-12-08 19:30 +0100
                Re: Where to report: root fails to edit other users file in sticky  bit directory MichaIng <micha@dietpi.com> - 2020-12-08 22:00 +0100
                Re: Where to report: root fails to edit other users file in sticky  bit directory Greg Wooledge <wooledg@eeg.ccf.org> - 2020-12-08 22:10 +0100
                Re: Where to report: root fails to edit other users file in sticky  bit directory MichaIng <micha@dietpi.com> - 2020-12-09 00:10 +0100
                Re: Where to report: root fails to edit other users file in sticky  bit directory Greg Wooledge <wooledg@eeg.ccf.org> - 2020-12-09 04:00 +0100
                Re: Where to report: root fails to edit other users file in sticky  bit directory MichaIng <micha@dietpi.com> - 2020-12-09 17:40 +0100
    Re: Where to report: root fails to edit other users file in sticky  bit directory Andrei POPESCU <andreimpopescu@gmail.com> - 2020-12-09 10:40 +0100
      Re: Where to report: root fails to edit other users file in sticky  bit directory MichaIng <micha@dietpi.com> - 2020-12-09 16:50 +0100
        Re: Where to report: root fails to edit other users file in sticky  bit directory Andrei POPESCU <andreimpopescu@gmail.com> - 2020-12-09 16:50 +0100

csiph-web