On Sat, Jul 16, 2011 at 01:01:22AM +0200, Michael Biebl wrote: > Am 16.07.2011 00:07, schrieb Trevour Crow: > > --- On Thu, 7/14/11, Michael Biebl <bi...@debian.org> wrote: > > > >> From: Michael Biebl <bi...@debian.org> > >> Subject: Re: Bug#633886: systemd chokes when /tmp is symlinked to /run/tmp > >> To: "Trevour Crow" <cro...@yahoo.com>, 633...@bugs.debian.org > >> Date: Thursday, July 14, 2011, 3:42 PM > > > >> Imho symlinking /tmp to /run/tmp is a stupid idea for various reasons. > >> If you want /tmp to be on a tmpfs, then make it a separate tmpfs. > >> That said, if you want the /run/tmp directory created automatically by > >> systemd, > >> you can drop a file in /etc/tmpfiles.d [1]. > >> I don't think such a file should be shipped by default in systemd though, > >> but > >> leave it up to Tollef to decide. > >> > > My main concern is the fact that systemd breaks on a system sysvinit > > supports > > without any warning(and initscripts's README.Debian gives no hint the > > configuration is anything but perfectly acceptable). Is there any reason > > that > > automating the workaround in systemd's postinst would be unacceptable? > > Something like this should catch most cases where the bug would manifest: > > > > if [ -h /tmp ]; then > > echo d $(readlink /tmp) 1777 root root - > > > /etc/tmpfiles.d/tmp-target.conf > > fi > > Hi Roger, > I'm wondering, what was the rationale behind introducing the /tmp → /run/tmp > symlink in sysvinit? Isn't that potentially dangerous, as /tmp is writable by > everyone thus making /run vulnerable to DoS? > While I can see the merit of a /tmp-on-tmpfs, the value behind /run/tmp is not > obvious to me. > Imho we shouldn't go overboard and stuff everything in /run now that we have > it.
I agree entirely. This is not intended to be used by default at all.
The actual feature in sysvinit uses this logic:
# If /tmp is a symlink, make sure the linked-to directory exists.
if [ -L /tmp ] && [ ! -d /tmp ]; then
TMPPATH="$(readlink /tmp)"
mkdir -p --mode=755 "$TMPPATH"
[ -x /sbin/restorecon ] && /sbin/restorecon "$TMPPATH"
fi
So it's not in any way specific to /run. If you make /tmp a symlink,
you can point it anywhere you like, and this logic just makes sure that
the path exists. If you point it to /run/tmp, then it will create
/run/tmp. But that's just one possibility.
The reason for having the logic is to allow consolidation of all
writable filesystems. This might be useful on embedded systems with
little memory for tmpfs, and where most things are read only, for
example. If you set RAMLOCK=no, RAMSHM=no and set /tmp to use /run/tmp,
all the writable stuff is in a single place. There are other
applications also, such as pointing /tmp to a large shared scratch space
in a cluster environment.
You are definitely correct that this makes /run vulnerable to DoS.
In consequence, I would not recommend this ever be used on a general
purpose system. The intent of the feature is to give flexibility to
implementors of special purpose resource-constrained systems.
> Unless there is a really good reason for /run/tmp, would you be willing to
> drop
> /run/tmp from sysvinit, so that we don't have to add any quirks in systemd to
> deal with that?
The support in initscripts is limited to the shell code above, from
mountkernfs. Looking at it some more, it's probably in the wrong
place (it should be after root is remounted rw and mountall in case
the path doesn't yet exist).
Regarding removal, I guess it depends upon whether having this
generic facility is considered a problem given the considerations I
mentioned above.
Regards,
Roger
--
.''`. Roger Leigh
: :' : Debian GNU/Linux http://people.debian.org/~rleigh/
`. `' Printing on GNU/Linux? http://gutenprint.sourceforge.net/
`- GPG Public Key: 0x25BFB848 Please GPG sign your mail.
signature.asc
Description: Digital signature
