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. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [PATCH] set sticky bit when creating /var/tmp mount-point
On Fri, Nov 16, 2001 at 01:41:52PM +1300, Mark van Walraven wrote: 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. bzzzt. thanks for playing. single-user mode has only one user remember, and that user is root, who can write anything. therefore the /tmp directories don't need to be world writable in single-user mode. 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. oh now /home and /usr/local are supposed to be world writable? Provided the default permissions are sensible. The ones created by dbootstrap for /var/tmp are not. i have yet to see any proof of this. -- Ethan Benson http://www.alaska.net/~erbenson/ msg12251/pgp0.pgp Description: PGP signature
Re: [PATCH] set sticky bit when creating /var/tmp mount-point
On Thu, Nov 15, 2001 at 03:51:55PM -0900, Ethan Benson wrote: On Fri, Nov 16, 2001 at 01:41:52PM +1300, Mark van Walraven wrote: 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. bzzzt. thanks for playing. single-user mode has only one user remember, and that user is root, who can write anything. The context was a system brought up in to multi-user mode without /var/tmp mounted. I wouldn't do that without an important reason, like perhaps a thousand users screaming for a critical application. But if /var/tmp is now writeable only by root, the critical application may well malfunction. 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. oh now /home and /usr/local are supposed to be world writable? similar, adj. Looking or being almost, but not exactly, the same. [Cambridge International Dictionary of English] The ownership and permissions of the /home and /usr/local mountpoints by dbootstrap should match those of the filesystems mounted on them. That's how they are almost the same. They should not be world writable. That's how they are not exactly the same. I assumed you would realise that. Provided the default permissions are sensible. The ones created by dbootstrap for /var/tmp are not. i have yet to see any proof of this. I don't believe you ever will see it. Mark. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [PATCH] set sticky bit when creating /var/tmp mount-point
On Fri, Nov 16, 2001 at 02:44:53PM +1300, Mark van Walraven wrote: On Thu, Nov 15, 2001 at 03:51:55PM -0900, Ethan Benson wrote: - i have yet to see any proof of this. I don't believe you ever will see it. I wish to apologise to Ethan and the list for my petulant and unfair remark. Regards, Mark. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [PATCH] set sticky bit when creating /var/tmp mount-point
On Thu, Nov 15, 2001 at 03:51:55PM -0900, Ethan Benson wrote: On Fri, Nov 16, 2001 at 01:41:52PM +1300, Mark van Walraven wrote: 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. bzzzt. thanks for playing. single-user mode has only one user remember, and that user is root, who can write anything. Inclusing su'ing to a user. Why should /var/tmp stop working if s/he does this? This is a trivial change, for an obvious purpose, with no drawbacks, why're you wasting your time arguing about it? Cheers, aj -- Anthony Towns [EMAIL PROTECTED] http://azure.humbug.org.au/~aj/ I don't speak for anyone save myself. GPG signed mail preferred. Security here. Yes, maam. Yes. Groucho glasses. Yes, we're on it. C'mon, guys. Somebody gave an aardvark a nose-cut: somebody who can't deal with deconstructionist humor. Code Blue. -- Mike Hoye, see http://azure.humbug.org.au/~aj/armadillos.txt -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
[PATCH] set sticky bit when creating /var/tmp mount-point
Dear list,
partition_config::mount_partition() uses mode 01777 when creating /tmp
as a mount-point, but doesn't for /target/var/tmp. A fix is:
Index: boot-floppies/utilities/dbootstrap/partition_config.c
===
RCS file: /cvs/debian-boot/boot-floppies/utilities/dbootstrap/partition_config.c,v
retrieving revision 1.116
diff -u -r1.116 partition_config.c
--- boot-floppies/utilities/dbootstrap/partition_config.c 2001/11/11 01:00:33
1.116
+++ boot-floppies/utilities/dbootstrap/partition_config.c 2001/11/13 09:36:48
@@ -572,7 +572,9 @@
while (1) {
if ((p = strchr(p + 1, '/')) != NULL)
*p = '\0';
- WithMode = strcmp(real_mount_point,/target/tmp) ? 0755 : 01777;
+ WithMode = strcmp(real_mount_point,/target/tmp)
+ strcmp(real_mount_point,/target/var/tmp)
+? 0755 : 01777;
DEBUGMSG(making mount point %s, real_mount_point);
if (! mkdir(real_mount_point, WithMode)) {
chmod(real_mount_point, WithMode);
Regards,
Mark.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [PATCH] set sticky bit when creating /var/tmp mount-point
On Tue, Nov 13, 2001 at 10:53:16PM +1300, Mark van Walraven wrote:
Dear list,
partition_config::mount_partition() uses mode 01777 when creating /tmp
as a mount-point, but doesn't for /target/var/tmp. A fix is:
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.
Index: boot-floppies/utilities/dbootstrap/partition_config.c
===
RCS file: /cvs/debian-boot/boot-floppies/utilities/dbootstrap/partition_config.c,v
retrieving revision 1.116
diff -u -r1.116 partition_config.c
--- boot-floppies/utilities/dbootstrap/partition_config.c 2001/11/11 01:00:33
1.116
+++ boot-floppies/utilities/dbootstrap/partition_config.c 2001/11/13 09:36:48
@@ -572,7 +572,9 @@
while (1) {
if ((p = strchr(p + 1, '/')) != NULL)
*p = '\0';
- WithMode = strcmp(real_mount_point,/target/tmp) ? 0755 : 01777;
+ WithMode = strcmp(real_mount_point,/target/tmp)
+strcmp(real_mount_point,/target/var/tmp)
+ ? 0755 : 01777;
DEBUGMSG(making mount point %s, real_mount_point);
if (! mkdir(real_mount_point, WithMode)) {
chmod(real_mount_point, WithMode);
Regards,
Mark.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
--
Ethan Benson
http://www.alaska.net/~erbenson/
msg12175/pgp0.pgp
Description: PGP signature
Re: [PATCH] set sticky bit when creating /var/tmp mount-point
Ethan Benson [EMAIL PROTECTED] writes: On Tue, Nov 13, 2001 at 10:53:16PM +1300, Mark van Walraven wrote: partition_config::mount_partition() uses mode 01777 when creating /tmp as a mount-point, but doesn't for /target/var/tmp. A fix is: 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. It enables the use of vi for non-root users even when /var/tmp isn't mounted ... uh ... No, actually, if you use tmpfs for /var/tmp, it will use the same permissions as the mount point, since there is no other place to store that persistent configuration. Kjetil T. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [PATCH] set sticky bit when creating /var/tmp mount-point
On Tue, Nov 13, 2001 at 12:02:18PM +0100, Kjetil Torgrim Homme wrote: Ethan Benson [EMAIL PROTECTED] writes: On Tue, Nov 13, 2001 at 10:53:16PM +1300, Mark van Walraven wrote: partition_config::mount_partition() uses mode 01777 when creating /tmp as a mount-point, but doesn't for /target/var/tmp. A fix is: 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. It enables the use of vi for non-root users even when /var/tmp isn't mounted ... uh ... and why would that happen? from a security point of view i think the directory under mountpoints like tmp should not be world writable, if the admin has a different filesystem/partition mounted there he probably did so to keep users from gaining write permission to the underlying filesystem (esp in the case of /). No, actually, if you use tmpfs for /var/tmp, it will use the same permissions as the mount point, since there is no other place to store that persistent configuration. this is not true: root@dogbert /# mkdir foo root@dogbert /# ls -ld foo/ drwxr-xr-x2 root root 1024 Nov 13 04:14 foo/ root@dogbert /# mount -t tmpfs tmpfs foo root@dogbert /# ls -ld foo/ drwxrwxrwt2 root root0 Nov 13 04:14 foo/ root@dogbert /# uname -a Linux dogbert 2.4.14 #1 Sun Nov 11 01:20:42 AKST 2001 ppc unknown default permissions for the tmpfs root is 1777 if you want something different you have to use the mode= mount option. -- Ethan Benson http://www.alaska.net/~erbenson/ msg12182/pgp0.pgp Description: PGP signature
Re: [PATCH] set sticky bit when creating /var/tmp mount-point
On Tue, Nov 13, 2001 at 04:20:36AM -0900, Ethan Benson wrote: On Tue, Nov 13, 2001 at 12:02:18PM +0100, Kjetil Torgrim Homme wrote: Ethan Benson [EMAIL PROTECTED] writes: - 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. It enables the use of vi for non-root users even when /var/tmp isn't mounted ... uh ... And many other things too! Bash, for instance uses TMPDIR for 'here documents'. and why would that happen? from a security point of view i think the directory under mountpoints like tmp should not be world writable, if the admin has a different filesystem/partition mounted there he probably did so to keep users from gaining write permission to the underlying filesystem (esp in the case of /). 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. 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. 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. Regards, Mark. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of unsubscribe. Trouble? Contact [EMAIL PROTECTED]
Re: [PATCH] set sticky bit when creating /var/tmp mount-point
On Wed, Nov 14, 2001 at 11:07:49AM +1300, Mark van Walraven wrote: On Tue, Nov 13, 2001 at 04:20:36AM -0900, Ethan Benson wrote: On Tue, Nov 13, 2001 at 12:02:18PM +0100, Kjetil Torgrim Homme wrote: Ethan Benson [EMAIL PROTECTED] writes: - 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. It enables the use of vi for non-root users even when /var/tmp isn't mounted ... uh ... And many other things too! Bash, for instance uses TMPDIR for 'here documents'. 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. unless your mounting a partition on /var/tmp we don't create it at all, base-files does. 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. 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. 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. if anything this sillyness regarding mountpoint directories should be removed, not expanded. 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. -- Ethan Benson http://www.alaska.net/~erbenson/ msg12201/pgp0.pgp Description: PGP signature
