On Thu, Apr 16, 2015 at 6:58 AM, Dennis Jacobfeuerborn <dennisml at conversis.de> wrote:> >> >> No, systemd actually remaps /tmp from apache - and apparently most >> other daemons - to private directories below /tmp with configs as >> shipped. The command line tool wrote the file to /tmp as expected. >> The perl code running under httpd reading what it thought was /tmp was >> actually looking under /tmp/systemd-private-something. I'm beginning >> to see why so much of EPEL isn't included in epel7 yet. > > The issue here really isn't systemd or the PrivateTmp feature but the > fact that some applications don't properly distinguish between temporary > files and data files.Maybe, but if an application wants a private directory for temporary files, shouldn't it create and manage that directory itself instead of being second-guessed by the default configuration of the OS?> Temporary files are files the application generates temporarily for > internal processing and that are not to be touched by anybody else. > If as in the twiki backup case the files generated are to be used by > somebody else after twiki is done generating them then these are regular > data files and not temporary files.This is very fuzzy... It is really all the application code creating/reading the files, and they are intended to be created at least daily with timestamps in the name and not live forever.> The application should have a configuration option to set its data > directory and it should default to /var/lib/<application-name>. > In cases where this option is not available and the application "abuses" > the tmp directory as data directory there is probably no other option > than to the set PrivateTmp=false in the service file.It does that - the issue is just that it is handy (and common) to use cron to do the scheduled runs and what the application sees as absolute file paths are perverted by the system into something surprising. The 'modern' approach might be to provide a rest type interface in the web application so the cron job could use wget/curl to access a URL instead of running the perl code itself. But that's also kind of weird to have to do to get a consistent view of the filesystem. And as far as what the default location should be - what would be correct for portable code? Isn't /var/lib/something kind of linux-centric? Where can an application expect to be able to write? -- Les Mikesell lesmikesell at gmail.com
On Thu, Apr 16, 2015 at 07:44:21AM -0500, Les Mikesell wrote:> > The issue here really isn't systemd or the PrivateTmp feature but the > > fact that some applications don't properly distinguish between temporary > > files and data files. > Maybe, but if an application wants a private directory for temporary > files, shouldn't it create and manage that directory itself instead of > being second-guessed by the default configuration of the OS?This one I have a clear answer for: no. It's the distribution's job to help regularize application practices, especially when they don't follow good practices for security. Ideally, we work with upstreams on this, but sometimes where it's just a matter of configuration, we choose to exercise options to make everything fit together.> filesystem. And as far as what the default location should be - > what would be correct for portable code? Isn't /var/lib/something > kind of linux-centric? Where can an application expect to be able to > write?Linux-centric? Linux/Unix-centric, maybe. I mean, that's not gonna work on VMS or MS Windows ? but then, neither is /tmp. -- Matthew Miller <mattdm at fedoraproject.org> Fedora Project Leader
On Thu, Apr 16, 2015 at 9:25 AM, Matthew Miller <mattdm at mattdm.org> wrote:> On Thu, Apr 16, 2015 at 07:44:21AM -0500, Les Mikesell wrote: >> > The issue here really isn't systemd or the PrivateTmp feature but the >> > fact that some applications don't properly distinguish between temporary >> > files and data files. >> Maybe, but if an application wants a private directory for temporary >> files, shouldn't it create and manage that directory itself instead of >> being second-guessed by the default configuration of the OS? > > This one I have a clear answer for: no. It's the distribution's job to > help regularize application practices, especially when they don't > follow good practices for security.Really? I would have expected that it was the distribution's job to not surprise coders or administrators. Particularly for 'enterprise' operating systems where the point is to keep the same application working the same way, often for the life of a company.> Ideally, we work with upstreams on > this, but sometimes where it's just a matter of configuration, we > choose to exercise options to make everything fit together.I typically have many web 'applications' running on the same system under the same apache instance, distinguished only by the top level directory in the url. Even if it made sense to someone to surprise these applications by remapping the filesystem for some reason, why would it make sense for them to share what the system thinks it is making private? -- Les Mikesell lesmikesell at gmail.com