| sean finney on 19 Aug 2010 00:28:04 -0700 |
|
hi joe,
(to others: apologies if this is kind of going off on a tangent, but i
figure it's still relevant at least)
for future reference, please don't break threads, it makes it very hard to
follow the line of conversation.
On Wed, Aug 18, 2010 at 08:46:22PM -0400, Joe Kisela wrote:
> Jeremy,
>
> Either your original message was unclear, or you have an opportunity to
> learn why what you stated wouldnt work without root priveledges, and why PAM
> generally doesnt follow symlinks. Jason pointed out, your scenario doesn't
> seem logical, but maybe we're missing something.
There are two vectors where mounting in /tmp could lead to the race
condition that jeremy talking about, and yes they're both theoretically
valid though only one would have me concerned as an admin. To stick
with A&B:
1) Alice knows Bob is going to mount on /tmp/target and knows that Bob either
doesn't sufficiently check the mountpoint first or that there is a
race condition between the Bob's checking and mounting where the attack
could take place.
2) Alice knows that the system uses a tmpfs mounted /tmp, such that Bob has
to set up the mountpoint again after a reboot, in which case she can insert
an @reboot cronjob or similar to beat Bob to the punch.
I wouldn't worry about 1) as much if it were only one-off mountings, but
2) could definitely be problematic.
Furthermore there are a number of systems that use a "/tmp-reaper" type
app to clean out files older than a certain age, so having a mountpoint
on these systems could end up introducing dataloss unexpectedly if you
have mounts there. Maybe not a problem for you on your own system if you
know you don't have this, but imagine starting a new job, making that
assumption, and nuking half of your employer's network filesystem.
So really /tmp does not seem the safest place for a couple reasons...
> http://www.pathname.com/fhs/pub/fhs-2.3.html , and yes, distros ignore them
> all the time. There are usually better places to put something than in /,
> that won't confuse the heck out of everyone. For the /Windows example,
FHS != POSIX, which is what you previously claimed, btw.
And as I've said before (in this topic as well as previous discussions)
nowhere does the FHS say that the _local admin_ can not create top-level
directories. The FHS actually says very little about what the local admin
can and can not do, it is a document like POSIX focused more app behavior
and the underlying OS (this is a pretty common misconception though).
In fact, on the matter of top-level directories it is even rather
acquiescent, stating that even OS distros can create their own top level
directories too, as long as they think hard about it first.
> that won't confuse the heck out of everyone. For the /Windows example,
> maybe /mnt/Windows is a better spot for it, and much more sensible, and
> doesn't break the standards just because you feel like adding a new root
> directory.
which standard were we talking about breaking again?
I would argue that /mnt/windows is not "more sensible" since in this case
(as opoosed to the above /tmp stuff) since we are talking about a persistant
mount point. it is not the purpose of the /mnt directory to have
persistant mountpoints, and I'd say it's better to pick a location
outside of the scope of the FHS and/or POSIX rather than mis-use an
already defined location within said scope.
But if you want to stay within the guidelines of the FHS there's always
/srv/win or maybe /usr/local/win, though if I ran the system I'd probably
still drop a symlink in / to point at it :)
sean
--
Attachment:
signature.asc ___________________________________________________________________________ Philadelphia Linux Users Group -- http://www.phillylinux.org Announcements - http://lists.phillylinux.org/mailman/listinfo/plug-announce General Discussion -- http://lists.phillylinux.org/mailman/listinfo/plug
|
|