Re: [PATCH] set sticky bit when creating /var/tmp mount-point
On Tue, Nov 13, 2001 at 03:06:38PM -0900, Ethan Benson wrote:
> your missing the point:
>
> > > > > what good will this do? the permissions of the mount point
> > > > > directory are irrelevant as they will be replaced by the
> > > > > permissions of the root directory of the mounted filesystem.
>
> this patch ONLY affects creation of the mountpoint directory which
> will be covered up by whatever partition/filesystem is mounted there.
But not until /etc/rcS.d/S35mountall.sh has run. And not if the admin
has un-mounted it for recovery or maintenence purposes.
> unless your mounting a partition on /var/tmp we don't create it at
> all, base-files does.
That's fine, but the patch addresses the case where /var/tmp is created
(as a mount-point) during the initial install.
> > It might happen because the admin temporarily un-mounted /var/tmp to
> > alter its size. Or perhaps the filesystem was damaged and the admin
> > decided to bring the system up without mounting it before trying to
> > recover the data. Maybe we simply one day decide we don't need /var/tmp
> > separate from /var.
>
> and for that reason he probably doesn't want lusers filling up /var
> while he is working.
If I didn't have important reason to get the system up quickly, I'd just
work away in single-user mode. If /var/tmp is only writeable by root,
some critical applications won't work properly.
> > Differing permissions on a filesystem and its mountpoint - in the absence
> > of admin intervention - violate the principle of least surprise for
> > most mount-points (obvious exceptions are /mnt, /cdrom and /floppy).
> > The inconsistency with /tmp is itself surprising.
>
> i disagree, lusers suddenly gaining write permission to a filesystem
> its not granted to them due to mountpoints is a surprise.
Hmmm. Lets see: I unmount /var/tmp and now the lusers suddenly have
write access to /var/tmp on the filesystem containing /var. Nope,
that doesn't surprise me at all.
> i would bet the only reason there is a special case kludge in
> boot-floppies here is due to severe misunderstanding of something by
> some other coder, i found many many instances of mkdir("/foo/bar",
> 1777) which does not work. the permission you specify is always ORed
> with the current umask, and the first digit is always ignored. you
> can't create a sticky directory with mkdir("blah", somemode) afaikt.
Yeah, the code in partition_config.c does a chmod() after the mkdir().
> if anything this sillyness regarding mountpoint directories should be
> removed, not expanded.
Well, /home and /usr/local have a similar problem, but I hadn't noticed
them until now. But that has a much lower impact, unlike the /var/tmp
problem, which I discovered early one morning when it bit me in the arse.
> > If I want to stop users writing into the /tmp and /var/tmp mountpoint
> > directories when nothing is mounted on them, then I change the
> > directory permissions in a deliberate act. However, since the system
> > will not automatically boot into multi-user mode without mounting all
> > the filesystems in fstab, I need not fear the mountpoints being exposed
> > without administrative fiat.
>
> yes so you agree the permissions of the mountpoint dir don't need to
> be fiddled with.
Provided the default permissions are sensible. The ones created by
dbootstrap for /var/tmp are not.
Regards,
Mark.
Reply to: