From debbugs-submit-bounces@debbugs.gnu.org Sat Dec 24 19:43:23 2011 Received: (at submit) by debbugs.gnu.org; 25 Dec 2011 00:43:23 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RecBN-0001vY-Pg for submit@debbugs.gnu.org; Sat, 24 Dec 2011 19:43:22 -0500 Received: from eggs.gnu.org ([140.186.70.92]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RecBI-0001vO-OL for submit@debbugs.gnu.org; Sat, 24 Dec 2011 19:43:18 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Rec8x-00089F-7E for submit@debbugs.gnu.org; Sat, 24 Dec 2011 19:40:52 -0500 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00, RCVD_IN_DNSWL_NONE, T_DKIM_INVALID autolearn=unavailable version=3.3.2 Received: from lists.gnu.org ([140.186.70.17]:33280) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Rec8x-00089B-5n for submit@debbugs.gnu.org; Sat, 24 Dec 2011 19:40:51 -0500 Received: from eggs.gnu.org ([140.186.70.92]:41276) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Rec8v-0003Eo-Qu for bug-coreutils@gnu.org; Sat, 24 Dec 2011 19:40:50 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Rec8u-00088v-EW for bug-coreutils@gnu.org; Sat, 24 Dec 2011 19:40:49 -0500 Received: from caiajhbdcbbj.dreamhost.com ([208.97.132.119]:58349 helo=homiemail-a7.g.dreamhost.com) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Rec8t-00088l-R3 for bug-coreutils@gnu.org; Sat, 24 Dec 2011 19:40:48 -0500 Received: from homiemail-a7.g.dreamhost.com (localhost [127.0.0.1]) by homiemail-a7.g.dreamhost.com (Postfix) with ESMTP id EC44425C063; Sat, 24 Dec 2011 16:40:44 -0800 (PST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=jidanni.org; h=from:to:cc:subject :references:date:message-id:mime-version:content-type; q=dns; s= jidanni.org; b=EtWUa89Rp7l6Cy4d+SoPg/sVT+oRYMS5uykZ5Vb+eEh+PYNF4 78NlWXmrnljOkC430XV2ZGaeYZwCek6Ro7TJBYjW59v++/Tkqg9jKceIl3fqfUOh 6GsG5mEb+zGPXzrL+njPFV7oFJb8lODPem0kqoA2iesLMHR6Hbc8R4YikA= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=jidanni.org; h=from:to:cc :subject:references:date:message-id:mime-version:content-type; s=jidanni.org; bh=9WwPpoLMFwMUWGEcebVG9yxtoXg=; b=lNJ6WyGbAKsr3 cC9nHI0xv+3o/56Fk5frOReuRjg90PNVsos8y07PbvlWpjMeSmsvYpe6Od2CYYlL FsqrmO+oivvBpDP0PnIN4vBizdA8ElJZjAn+SY5PGZTlDbbY568zaOXVPvwdW0t4 iRx/WQDETID4JZUvn30GVNIUQOK+64= Received: from jidanni.org (218-163-20-32.dynamic.hinet.net [218.163.20.32]) (using TLSv1 with cipher AES256-SHA (256/256 bits)) (No client certificate requested) (Authenticated sender: jidanni@jidanni.org) by homiemail-a7.g.dreamhost.com (Postfix) with ESMTPSA id 4536525C062; Sat, 24 Dec 2011 16:40:44 -0800 (PST) From: jidanni@jidanni.org To: rleigh@codelibre.net, debian-devel@lists.debian.org Subject: /etc/mtab -> /proc/mounts symlink affects df(1) output for / References: <20111224164832.GT5437@codelibre.net> Date: Sun, 25 Dec 2011 08:40:42 +0800 Message-ID: <874nwpzdo5.fsf_-_@jidanni.org> MIME-Version: 1.0 Content-Type: text/plain X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-Received-From: 140.186.70.17 X-Spam-Score: -5.4 (-----) X-Debbugs-Envelope-To: submit Cc: 653073@bugs.debian.org, bug-coreutils@gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -5.4 (-----) The new symlink on Debian, $ ls -og /etc/mtab lrwxrwxrwx 1 12 12-23 22:00 /etc/mtab -> /proc/mounts Has caused $ df Filesystem 1K-blocks Used Available Use% Mounted on rootfs 1071468 287940 729100 29% / udev 248048 0 248048 0% /dev tmpfs 50564 372 50192 1% /run /dev/disk/by-uuid/551e44e1-2cad-42cf-a716-f2e6caf9dc78 1071468 287940 729100 29% / tmpfs 101128 712 100416 1% /tmp tmpfs 101128 0 101128 0% /run/shm /dev/sda6 4270273 3711316 341987 92% /home /dev/sda7 5341549 4336289 733858 86% /var /dev/sda8 6406856 3024600 3056800 50% /usr output to 1) repeat / twice, 2) give the long name for /. This should be reproducible for anyone who has used standard grub and thus has $ grep -h UUID /boot/grub/grub.cfg /proc/cmdline matches. More details in http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=653073 . From debbugs-submit-bounces@debbugs.gnu.org Mon Dec 26 18:29:43 2011 Received: (at 10363) by debbugs.gnu.org; 26 Dec 2011 23:29:43 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RfJzD-0008MV-90 for submit@debbugs.gnu.org; Mon, 26 Dec 2011 18:29:43 -0500 Received: from c-68-60-252-82.hsd1.in.comcast.net ([68.60.252.82] helo=kosh.dhis.org) by debbugs.gnu.org with smtp (Exim 4.69) (envelope-from ) id 1RfJzB-0008MO-6U for 10363@debbugs.gnu.org; Mon, 26 Dec 2011 18:29:41 -0500 Received: (qmail 29922 invoked by uid 1000); 26 Dec 2011 23:27:05 -0000 Message-ID: <20111226232705.29921.qmail@kosh.dhis.org> From: "Alan Curry" Subject: Re: bug#10363: /etc/mtab -> /proc/mounts symlink affects df(1) output for To: jidanni@jidanni.org Date: Mon, 26 Dec 2011 18:27:05 -0500 (GMT+5) In-Reply-To: <874nwpzdo5.fsf_-_@jidanni.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 10363 Cc: 653073@bugs.debian.org, rleigh@codelibre.net, debian-devel@lists.debian.org, 10363@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -0.7 (/) jidanni@jidanni.org writes: > > Filesystem 1K-blocks Used Available Use% Mounted on > rootfs 1071468 287940 729100 29% / > /dev/disk/by-uuid/551e44e1-2cad-42cf-a716-f2e6caf9dc78 1071468 287940 729100 29% / (I'm replying only on the issue of the duplicate mount point. Someone else can tackle the long ugly name.) The one with "rootfs" as its device is the initramfs which you automatically get with all recent kernels. Even if you aren't using an initramfs, there's an empty one built into the kernel which gets mounted as the first root filesystem. The real root gets mounted on top of that. So this is a special case of a general problem with no easy solution: What should df do when 2 filesystems are mounted at the same location? It can't easily give correct information for both of them, since the later mount obscures the earlier mount from view. If there's a way for df to get the correct information for the lower mount, I don't know what it would be. If you have a process with a leftover cwd or open fd in the obscured filesystem, you can use that. But generally you won't. But maybe we could do better than reporting incorrectly that the lower mount has size and usage identical to the upper mount! At least df could print a warning at the end if it has seen any duplicate entries. Perhaps there is some way it could figure out which one is on top, and print a bunch of question marks as the lower mount's statistics. If df is running as root, it might be able to unshare(2) the mount namespace, unmount the upper level, and then statfs the mount point again to get the correct results for the lower level. That won't work in all cases (even in a private namespace you can't unmount the filesystem containing your own cwd) and it does nothing for you if you're not root, but still... it would be a cool bonus in the cases where it does work. As a special case, "rootfs" should probably be excluded from the default listing, since the initramfs is not very interesting most of the time. It could still be shown with the -a option, although it would always have the wrong statistics. Or if you really want to be impressive, default to showing the initramfs if and only if it is the only thing mounted on "/" - so you can run df within the initramfs before the real root is mounted and get the right result. Or... (brace yourself for the most bold idea yet)... can you imagine a kernel interface that would *cleanly* give access to obscured mount points? Comments on any of the above? Do the BSDs have any bright ideas we can steal, or is their df as embarrassingly bad at handling obscured mount points as ours? -- Alan Curry From debbugs-submit-bounces@debbugs.gnu.org Thu Dec 29 09:11:58 2011 Received: (at 10363) by debbugs.gnu.org; 29 Dec 2011 14:11:58 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RgGi5-0002LF-L2 for submit@debbugs.gnu.org; Thu, 29 Dec 2011 09:11:57 -0500 Received: from mx.meyering.net ([88.168.87.75]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RgGi2-0002L6-Pm for 10363@debbugs.gnu.org; Thu, 29 Dec 2011 09:11:56 -0500 Received: from rho.meyering.net (localhost.localdomain [127.0.0.1]) by rho.meyering.net (Acme Bit-Twister) with ESMTP id 22B3860130; Thu, 29 Dec 2011 15:09:03 +0100 (CET) From: Jim Meyering To: coreutils@gnu.org Subject: df vs. long-named /dev/disk/by-uuid/... file system device names Date: Thu, 29 Dec 2011 15:09:03 +0100 Message-ID: <87ty4jcvwg.fsf@rho.meyering.net> Lines: 227 MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -2.7 (--) X-Debbugs-Envelope-To: 10363 Cc: 10363@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.7 (--) On systems with recent kernel/tools, a symlink from /etc/mtab to /proc/mounts, and a by-UUID mount (i.e., soon, nearly everyone), you will see something like the following when running "df -hT": Filesystem Type Size Used Avail Use% Mounted on rootfs rootfs 11G 1.9G 8.0G 19% / udev devtmpfs 3.8G 0 3.8G 0% /dev tmpfs tmpfs 774M 376K 774M 1% /run /dev/disk/by-uuid/828fc648-9f30-43d8-a0b1-f7096a2edb66 ext4 11G 1.9G 8.0G 19% / tmpfs tmpfs 1.6G 8.0K 1.6G 1% /run/shm /dev/sda2 ext3 494M 78M 392M 17% /boot /dev/sda5 ext4 12G 7.6G 3.7G 68% /usr /dev/sda6 ext4 9.9G 6.6G 2.8G 71% /var Contrast that with what we're used to seeing (modulo the two entries mounted on "/", which is a separate problem): Filesystem Type Size Used Avail Use% Mounted on rootfs rootfs 11G 1.9G 8.0G 19% / udev devtmpfs 3.8G 0 3.8G 0% /dev tmpfs tmpfs 774M 376K 774M 1% /run /dev/sda3 ext4 11G 1.9G 8.0G 19% / tmpfs tmpfs 1.6G 8.0K 1.6G 1% /run/shm /dev/sda2 ext3 494M 78M 392M 17% /boot /dev/sda5 ext4 12G 7.6G 3.7G 68% /usr /dev/sda6 ext4 9.9G 6.6G 2.8G 71% /var When that long /dev/disk/by-*/... name is merely a symlink to a much shorter (and often more useful) device name like "/dev/sda3", and when it's part of a listing of all file systems, I would much prefer to see only the latter. I.e., if I explicitly run "df -hT /dev/disk/by-uuid/828fc648-9f30-43d8-a0b1-f7096a2edb66", *then*, it's fine -- and expected -- to print to the long name. It was explicitly given. However, with no non-option argument, df should print the shorter name. Note that performing this translation at a lower level (via a change to gnulib's mountlist.c) would make it impossible to distinguish those two cases. Here's a patch to do that. It's a little larger than you might expect because of two factors: - it modifies each of five get_dev call-points - to avoid introducing a leak, it allocates space for dev_name earlier I hesitated to make this change, because it feels like a kludge that's working around a misfeature that should be fixed elsewhere. I'd rather that the long root device name not appear in the mount listing (/proc/mounts) in the first place. If anyone can assure us that this will soon be "fixed" so that we don't get such entries in /proc/mounts quite so easily, I'll be happy to defer or drop the patch. >From a59338b9ca2ed8cbc82bdf3a299c4a664ad113c9 Mon Sep 17 00:00:00 2001 From: Jim Meyering Date: Thu, 29 Dec 2011 14:49:00 +0100 Subject: [PATCH] df: work around long-named /dev/disk/by-uuid/... symlinks On systems with recent kernel/tools, a symlink from /etc/mtab to /proc/mounts, and a by-UUID mount (i.e., soon, nearly everyone), you will see something like the following when running "df -hT": (this has been truncated to fit in a width-limited ChangeLog file) Filesystem Type Siz... rootfs rootfs 11G udev devtmpfs 3.8G tmpfs tmpfs 774M /dev/disk/by-uuid/828fc648-9f30-43d8-a0b1-f7096a2edb66 ext4 11G tmpfs tmpfs 1.6G /dev/sda2 ext3 494M /dev/sda5 ext4 12G /dev/sda6 ext4 9.9G Contrast that with what we're used to seeing (modulo the two entries mounted on "/", which is a separate problem): Filesystem Type Size Used Avail Use% Mounted on rootfs rootfs 11G 1.9G 8.0G 19% / udev devtmpfs 3.8G 0 3.8G 0% /dev tmpfs tmpfs 774M 376K 774M 1% /run /dev/sda3 ext4 11G 1.9G 8.0G 19% / tmpfs tmpfs 1.6G 8.0K 1.6G 1% /run/shm /dev/sda2 ext3 494M 78M 392M 17% /boot /dev/sda5 ext4 12G 7.6G 3.7G 68% /usr /dev/sda6 ext4 9.9G 6.6G 2.8G 71% /var When that long /dev/disk/by-*/... name is merely a symlink to a much shorter (and often more useful) device name like "/dev/sda3", and when it's part of a listing of all file systems, I would much prefer to see only the latter. I.e., if I explicitly run "df -hT /dev/disk/by-uuid/828fc648-9f30-43d8-a0b1-f7096a2edb66", Then, it's fine -- and expected -- to print to the long name. It was explicitly given. However, with no non-option argument, df should print the shorter name. Note that performing this translation at a lower level (via a change to gnulib's mountlist.c) would make it impossible to distinguish those two cases. * src/df.c: Include "canonicalize.h". (get_dev): Add a parameter, telling when to resolve device symlinks and update all callers. When true, resolve a symlink name to a shorter referent. Reported by Dan Jacobson in http://bugs.gnu.org/10363 --- src/df.c | 43 +++++++++++++++++++++++++++++++++++-------- 1 files changed, 35 insertions(+), 8 deletions(-) diff --git a/src/df.c b/src/df.c index 982d607..516288b 100644 --- a/src/df.c +++ b/src/df.c @@ -25,6 +25,7 @@ #include #include "system.h" +#include "canonicalize.h" #include "error.h" #include "fsusage.h" #include "human.h" @@ -428,13 +429,16 @@ add_uint_with_neg_flag (uintmax_t *dest, bool *dest_neg, If FSTYPE is non-NULL, it is the type of the file system on DISK. If MOUNT_POINT is non-NULL, then DISK may be NULL -- certain systems may not be able to produce statistics in this case. - ME_DUMMY and ME_REMOTE are the mount entry flags. */ + ME_DUMMY and ME_REMOTE are the mount entry flags. + RESOLVE_DEVICE_SYMLINK is true when iterating over all entries, as when + df is invoked with no non-option argument. See below for details. */ static void get_dev (char const *disk, char const *mount_point, char const *stat_file, char const *fstype, bool me_dummy, bool me_remote, - const struct fs_usage *force_fsu) + const struct fs_usage *force_fsu, + bool resolve_device_symlink) { struct fs_usage fsu; char buf[LONGEST_HUMAN_READABLE + 2]; @@ -488,6 +492,29 @@ get_dev (char const *disk, char const *mount_point, if (! disk) disk = "-"; /* unknown */ + + char *dev_name = xstrdup (disk); + char *resolved_dev; + size_t orig_len = strlen (dev_name); + + /* If dev_name is a long-named symlink like + /dev/disk/by-uuid/828fc648-9f30-43d8-a0b1-f7196a2edb66 and its + canonical name is shorter, use the shorter name. But don't bother + checking when DEV_NAME is no longer than e.g., "/dev/sda1" */ + if (resolve_device_symlink && 9 < orig_len + && (resolved_dev = canonicalize_filename_mode (dev_name, CAN_EXISTING))) + { + if (strlen (resolved_dev) < orig_len) + { + free (dev_name); + dev_name = resolved_dev; + } + else + { + free (resolved_dev); + } + } + if (! fstype) fstype = "-"; /* unknown */ @@ -537,7 +564,7 @@ get_dev (char const *disk, char const *mount_point, switch (field) { case DEV_FIELD: - cell = xstrdup (disk); + cell = dev_name; break; case TYPE_FIELD: @@ -648,7 +675,7 @@ get_disk (char const *disk) { get_dev (best_match->me_devname, best_match->me_mountdir, NULL, best_match->me_type, best_match->me_dummy, - best_match->me_remote, NULL); + best_match->me_remote, NULL, false); return true; } @@ -734,7 +761,7 @@ get_point (const char *point, const struct stat *statp) if (best_match) get_dev (best_match->me_devname, best_match->me_mountdir, point, best_match->me_type, best_match->me_dummy, best_match->me_remote, - NULL); + NULL, false); else { /* We couldn't find the mount entry corresponding to POINT. Go ahead and @@ -745,7 +772,7 @@ get_point (const char *point, const struct stat *statp) char *mp = find_mount_point (point, statp); if (mp) { - get_dev (NULL, mp, NULL, NULL, false, false, NULL); + get_dev (NULL, mp, NULL, NULL, false, false, NULL, false); free (mp); } } @@ -774,7 +801,7 @@ get_all_entries (void) for (me = mount_list; me; me = me->me_next) get_dev (me->me_devname, me->me_mountdir, NULL, me->me_type, - me->me_dummy, me->me_remote, NULL); + me->me_dummy, me->me_remote, NULL, true); } /* Add FSTYPE to the list of file system types to display. */ @@ -1066,7 +1093,7 @@ main (int argc, char **argv) { if (inode_format) grand_fsu.fsu_blocks = 1; - get_dev ("total", NULL, NULL, NULL, false, false, &grand_fsu); + get_dev ("total", NULL, NULL, NULL, false, false, &grand_fsu, false); } print_table (); -- 1.7.7.3 From debbugs-submit-bounces@debbugs.gnu.org Thu Dec 29 11:05:25 2011 Received: (at 10363) by debbugs.gnu.org; 29 Dec 2011 16:05:25 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RgITs-00050r-4K for submit@debbugs.gnu.org; Thu, 29 Dec 2011 11:05:25 -0500 Received: from mail1.vodafone.ie ([213.233.128.43]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RgITq-00050j-5s for 10363@debbugs.gnu.org; Thu, 29 Dec 2011 11:05:23 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: ApMBACKO/E5tTlDs/2dsb2JhbAAMN6oJhVoBAQEEMgFGEAsNCwkWDwkDAgECAUUGDQEHAQG9UoN9iBIEmnGMRQ Received: from unknown (HELO [192.168.1.79]) ([109.78.80.236]) by mail1.vodafone.ie with ESMTP; 29 Dec 2011 16:02:30 +0000 Message-ID: <4EFC8F00.4000008@draigBrady.com> Date: Thu, 29 Dec 2011 16:02:08 +0000 From: =?ISO-8859-1?Q?P=E1draig_Brady?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:6.0) Gecko/20110816 Thunderbird/6.0 MIME-Version: 1.0 To: Jim Meyering Subject: Re: bug#10363: df vs. long-named /dev/disk/by-uuid/... file system device names References: <874nwpzdo5.fsf_-_@jidanni.org> <87ty4jcvwg.fsf@rho.meyering.net> In-Reply-To: <87ty4jcvwg.fsf@rho.meyering.net> X-Enigmail-Version: 1.3.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.5 (--) X-Debbugs-Envelope-To: 10363 Cc: 10363@debbugs.gnu.org, coreutils@gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.5 (--) On 12/29/2011 02:09 PM, Jim Meyering wrote: > On systems with recent kernel/tools, a symlink from /etc/mtab to > /proc/mounts, and a by-UUID mount (i.e., soon, nearly everyone), > you will see something like the following when running "df -hT": > > Filesystem Type Size Used Avail Use% Mounted on > rootfs rootfs 11G 1.9G 8.0G 19% / > /dev/disk/by-uuid/828fc648-9f30-43d8-a0b1-f7096a2edb66 ext4 11G 1.9G 8.0G 19% / Ouch. BTW, this is the first mail I've gotten about 10363? I guess this is the right thing to do. I.E. have higher level paths in /proc/mounts, allowing tools that require lower level paths to traverse the links and pick the appropriate one. The highest level path needs to be available to do this, so I suppose this is appropriate in /proc/mounts, even though it might not be the most appropriate for human consumption, as can be seen above. The patch looks good. I guess "9" is the only questionable bit. On my Fedora 16 system I have in /proc/mounts: /dev/mapper/vg_tp1-lv_root ...... / That's a fairly informative name, whereas the links further resolve to a fairly generic: /dev/dm-2 Hmm, I was contemplating using the old wrap limit of 19, but apart from not handling the above, using a width is inconsistent. Perhaps it's better to always resolve? I.E. always print the base device. It seems that one can work back from this anyway: $ findmnt --source /dev/dm-2 TARGET SOURCE FSTYPE OPTIONS / /dev/mapper/vg_tp1-lv_root ext4 rw,relatime,... cheers, Pádraig. From debbugs-submit-bounces@debbugs.gnu.org Thu Dec 29 11:56:07 2011 Received: (at 10363) by debbugs.gnu.org; 29 Dec 2011 16:56:07 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RgJGv-00069V-TK for submit@debbugs.gnu.org; Thu, 29 Dec 2011 11:56:06 -0500 Received: from smtp.cs.ucla.edu ([131.179.128.62]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RgJGu-00069O-3C for 10363@debbugs.gnu.org; Thu, 29 Dec 2011 11:56:05 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp.cs.ucla.edu (Postfix) with ESMTP id 3DCECA60004; Thu, 29 Dec 2011 08:53:12 -0800 (PST) X-Virus-Scanned: amavisd-new at smtp.cs.ucla.edu Received: from smtp.cs.ucla.edu ([127.0.0.1]) by localhost (smtp.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id Yu3IqJun66sd; Thu, 29 Dec 2011 08:53:11 -0800 (PST) Received: from [192.168.1.10] (pool-71-189-109-235.lsanca.fios.verizon.net [71.189.109.235]) by smtp.cs.ucla.edu (Postfix) with ESMTPSA id 8CE1AA60001; Thu, 29 Dec 2011 08:53:11 -0800 (PST) Message-ID: <4EFC9AF2.305@cs.ucla.edu> Date: Thu, 29 Dec 2011 08:53:06 -0800 From: Paul Eggert Organization: UCLA Computer Science Department User-Agent: Mozilla/5.0 (X11; Linux i686; rv:8.0) Gecko/20111124 Thunderbird/8.0 MIME-Version: 1.0 To: Jim Meyering Subject: Re: bug#10363: df vs. long-named /dev/disk/by-uuid/... file system device names References: <874nwpzdo5.fsf_-_@jidanni.org> <87ty4jcvwg.fsf@rho.meyering.net> In-Reply-To: <87ty4jcvwg.fsf@rho.meyering.net> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Spam-Score: -2.9 (--) X-Debbugs-Envelope-To: 10363 Cc: 10363@debbugs.gnu.org, coreutils@gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.9 (--) On 12/29/11 06:09, Jim Meyering wrote: > + /* If dev_name is a long-named symlink like > + /dev/disk/by-uuid/828fc648-9f30-43d8-a0b1-f7196a2edb66 and its > + canonical name is shorter, use the shorter name. But don't bother > + checking when DEV_NAME is no longer than e.g., "/dev/sda1" */ > + if (resolve_device_symlink && 9 < orig_len > + && (resolved_dev = canonicalize_filename_mode (dev_name, CAN_EXISTING))) > + { > + if (strlen (resolved_dev) < orig_len) > + { > + free (dev_name); > + dev_name = resolved_dev; > + } > + else > + { > + free (resolved_dev); > + } > + } I have some qualms about that "is shorter" part; couldn't that lead to confusing results, on systems where the canonical name is sometimes a bit shorter and sometimes a bit longer? Also, that "9 < orig_len" could also cause confusion. The flag "resolve_device_symlink" suggests that the name should always be resolved, at any rate. In short, how a simpler approach, that always resolves symlinks? Something like this: /* If dev_name is a symlink use the resolved name. On recent GNU/Linux systems we often see a symlink from, e.g., /dev/disk/by-uuid/828fc648-9f30-43d8-a0b1-f7196a2edb66 tp /dev/sda3 and it's better to output /dev/sda3. */ if (resolve_device_symlink && (resolved_dev = canonicalize_filename_mode (dev_name, CAN_EXISTING))) { free (dev_name); dev_name = resolved_dev; } From debbugs-submit-bounces@debbugs.gnu.org Thu Dec 29 12:42:31 2011 Received: (at 10363) by debbugs.gnu.org; 29 Dec 2011 17:42:31 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RgJzq-0007EX-8m for submit@debbugs.gnu.org; Thu, 29 Dec 2011 12:42:31 -0500 Received: from joseki.proulx.com ([216.17.153.58]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RgJzm-0007EO-Dl for 10363@debbugs.gnu.org; Thu, 29 Dec 2011 12:42:27 -0500 Received: from hysteria.proulx.com (hysteria.proulx.com [192.168.230.119]) by joseki.proulx.com (Postfix) with ESMTP id 7FA06211D2; Thu, 29 Dec 2011 10:39:34 -0700 (MST) Received: by hysteria.proulx.com (Postfix, from userid 1000) id 1D9382DC9D; Thu, 29 Dec 2011 10:39:34 -0700 (MST) Date: Thu, 29 Dec 2011 10:39:34 -0700 From: Bob Proulx To: Jim Meyering Subject: Re: df vs. long-named /dev/disk/by-uuid/... file system device names Message-ID: <20111229173934.GA2044@hysteria.proulx.com> Mail-Followup-To: Jim Meyering , coreutils@gnu.org, 10363@debbugs.gnu.org References: <87ty4jcvwg.fsf@rho.meyering.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87ty4jcvwg.fsf@rho.meyering.net> User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Score: -2.5 (--) X-Debbugs-Envelope-To: 10363 Cc: 10363@debbugs.gnu.org, coreutils@gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.5 (--) Jim Meyering wrote: > On systems with recent kernel/tools, a symlink from /etc/mtab to > /proc/mounts, and a by-UUID mount (i.e., soon, nearly everyone), > you will see something like the following when running "df -hT": Very unpleasant output. > Here's a patch to do that. > ... > I hesitated to make this change, because it feels like a kludge that's > working around a misfeature that should be fixed elsewhere. I'd rather > that the long root device name not appear in the mount listing > (/proc/mounts) in the first place. > > If anyone can assure us that this will soon be "fixed" so that we > don't get such entries in /proc/mounts quite so easily, I'll be > happy to defer or drop the patch. +1 vote for doing something, either this or similar, to address the issue in the coreutils df. Otherwise there will be an endless stream of annoyed people knocking down the door of the messenger. Bob From debbugs-submit-bounces@debbugs.gnu.org Fri Dec 30 08:55:14 2011 Received: (at 10363) by debbugs.gnu.org; 30 Dec 2011 13:55:15 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RgcvS-00056M-Bv for submit@debbugs.gnu.org; Fri, 30 Dec 2011 08:55:14 -0500 Received: from mx.meyering.net ([88.168.87.75]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RgcvO-00056C-E1 for 10363@debbugs.gnu.org; Fri, 30 Dec 2011 08:55:12 -0500 Received: from rho.meyering.net (localhost.localdomain [127.0.0.1]) by rho.meyering.net (Acme Bit-Twister) with ESMTP id B6F4E60079; Fri, 30 Dec 2011 14:52:13 +0100 (CET) From: Jim Meyering To: Paul Eggert Subject: Re: bug#10363: df vs. long-named /dev/disk/by-uuid/... file system device names In-Reply-To: <4EFC9AF2.305@cs.ucla.edu> (Paul Eggert's message of "Thu, 29 Dec 2011 08:53:06 -0800") References: <874nwpzdo5.fsf_-_@jidanni.org> <87ty4jcvwg.fsf@rho.meyering.net> <4EFC9AF2.305@cs.ucla.edu> Date: Fri, 30 Dec 2011 14:52:13 +0100 Message-ID: <8739c2b20i.fsf@rho.meyering.net> Lines: 236 MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -2.7 (--) X-Debbugs-Envelope-To: 10363 Cc: 10363@debbugs.gnu.org, coreutils@gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.7 (--) Paul Eggert wrote: > On 12/29/11 06:09, Jim Meyering wrote: >> + /* If dev_name is a long-named symlink like >> + /dev/disk/by-uuid/828fc648-9f30-43d8-a0b1-f7196a2edb66 and its >> + canonical name is shorter, use the shorter name. But don't bother >> + checking when DEV_NAME is no longer than e.g., "/dev/sda1" */ >> + if (resolve_device_symlink && 9 < orig_len >> + && (resolved_dev = canonicalize_filename_mode (dev_name, CAN_EXISTING))) >> + { >> + if (strlen (resolved_dev) < orig_len) >> + { >> + free (dev_name); >> + dev_name = resolved_dev; >> + } >> + else >> + { >> + free (resolved_dev); >> + } >> + } > > I have some qualms about that "is shorter" part; > couldn't that lead to confusing results, on systems > where the canonical name is sometimes a bit shorter and sometimes > a bit longer? > > Also, that "9 < orig_len" could also cause confusion. > > The flag "resolve_device_symlink" suggests that > the name should always be resolved, at any rate. > > In short, how a simpler approach, that always resolves > symlinks? Something like this: > > /* If dev_name is a symlink use the resolved name. > On recent GNU/Linux systems we often see a symlink from, e.g., > /dev/disk/by-uuid/828fc648-9f30-43d8-a0b1-f7196a2edb66 > tp /dev/sda3 and it's better to output /dev/sda3. */ > if (resolve_device_symlink > && (resolved_dev = canonicalize_filename_mode (dev_name, CAN_EXISTING))) > { > free (dev_name); > dev_name = resolved_dev; > } Thanks for the suggestion. I've dropped the 9 < ... part, but since this is (at least planned) to be the default, I want to limit the scope of the change to those very long by-uuid symlinks, so I've adjusted it like this: /* On some systems, dev_name is a long-named symlink like /dev/disk/by-uuid/828fc648-9f30-43d8-a0b1-f7196a2edb66 pointing to a much shorter and more useful name like /dev/sda1. When resolve_device_symlink is true and dev_name is a symlink whose name starts with /dev/disk/by-uuid/ use the resolved name instead. */ if (resolve_device_symlink && STRPREFIX (dev_name, "/dev/disk/by-uuid/") && (resolved_dev = canonicalize_filename_mode (dev_name, CAN_EXISTING))) { free (dev_name); dev_name = resolved_dev; } I considered matching only "/dev/disk/by-", in case some initrd uses by-id, by-label or by-path, but I doubt that will happen often enough, so will keep this change very precisely targeted. I've also changed the parameter name from resolve_device_symlink to process_all. I don't particular like that name either. Suggestions welcome. >From fb52b3722433d88af8ca8912d3cac531e04bf585 Mon Sep 17 00:00:00 2001 From: Jim Meyering Date: Thu, 29 Dec 2011 14:49:00 +0100 Subject: [PATCH] df: work around long-named /dev/disk/by-uuid/... symlinks On systems with recent kernel/tools, a symlink from /etc/mtab to /proc/mounts, and a by-UUID mount (i.e., soon, nearly everyone), you will see something like the following when running "df -hT": (this has been truncated to fit in a width-limited ChangeLog file) Filesystem Type Siz... rootfs rootfs 11G udev devtmpfs 3.8G tmpfs tmpfs 774M /dev/disk/by-uuid/828fc648-9f30-43d8-a0b1-f7096a2edb66 ext4 11G tmpfs tmpfs 1.6G /dev/sda2 ext3 494M /dev/sda5 ext4 12G /dev/sda6 ext4 9.9G Contrast that with what we're used to seeing (modulo the two entries mounted on "/", which is a separate problem): Filesystem Type Size Used Avail Use% Mounted on rootfs rootfs 11G 1.9G 8.0G 19% / udev devtmpfs 3.8G 0 3.8G 0% /dev tmpfs tmpfs 774M 376K 774M 1% /run /dev/sda3 ext4 11G 1.9G 8.0G 19% / tmpfs tmpfs 1.6G 8.0K 1.6G 1% /run/shm /dev/sda2 ext3 494M 78M 392M 17% /boot /dev/sda5 ext4 12G 7.6G 3.7G 68% /usr /dev/sda6 ext4 9.9G 6.6G 2.8G 71% /var When that long /dev/disk/by-uuid/... name is merely a symlink to a much shorter (and often more useful) device name like "/dev/sda3", and when it's part of a listing of all file systems, I would much prefer to see only the latter. I.e., if I explicitly run "df -hT /dev/disk/by-uuid/828fc648-9f30-43d8-a0b1-f7096a2edb66", then, it's fine -- and expected -- to print to the long name. It was explicitly given. However, with no non-option argument, df should print the shorter name. Note that performing this translation at a lower level (via a change to gnulib's mountlist.c) would make it impossible to distinguish those two cases. * src/df.c: Include "canonicalize.h". (get_dev): Add a parameter, telling when we're in process-all- mount-points mode; update all callers. When true, resolve /dev/disk/by-uuid/... symlinks. Reported by Dan Jacobson in http://bugs.gnu.org/10363 --- src/df.c | 37 +++++++++++++++++++++++++++++-------- 1 files changed, 29 insertions(+), 8 deletions(-) diff --git a/src/df.c b/src/df.c index 982d607..cedb583 100644 --- a/src/df.c +++ b/src/df.c @@ -25,6 +25,7 @@ #include #include "system.h" +#include "canonicalize.h" #include "error.h" #include "fsusage.h" #include "human.h" @@ -428,13 +429,16 @@ add_uint_with_neg_flag (uintmax_t *dest, bool *dest_neg, If FSTYPE is non-NULL, it is the type of the file system on DISK. If MOUNT_POINT is non-NULL, then DISK may be NULL -- certain systems may not be able to produce statistics in this case. - ME_DUMMY and ME_REMOTE are the mount entry flags. */ + ME_DUMMY and ME_REMOTE are the mount entry flags. + Caller must set PROCESS_ALL to true when iterating over all entries, as + when df is invoked with no non-option argument. See below for details. */ static void get_dev (char const *disk, char const *mount_point, char const *stat_file, char const *fstype, bool me_dummy, bool me_remote, - const struct fs_usage *force_fsu) + const struct fs_usage *force_fsu, + bool process_all) { struct fs_usage fsu; char buf[LONGEST_HUMAN_READABLE + 2]; @@ -488,6 +492,23 @@ get_dev (char const *disk, char const *mount_point, if (! disk) disk = "-"; /* unknown */ + + char *dev_name = xstrdup (disk); + char *resolved_dev; + + /* On some systems, dev_name is a long-named symlink like + /dev/disk/by-uuid/828fc648-9f30-43d8-a0b1-f7196a2edb66 pointing + to a much shorter and more useful name like /dev/sda1. + When process_all is true and dev_name is a symlink whose name starts + with /dev/disk/by-uuid/ use the resolved name instead. */ + if (process_all + && STRPREFIX (dev_name, "/dev/disk/by-uuid/") + && (resolved_dev = canonicalize_filename_mode (dev_name, CAN_EXISTING))) + { + free (dev_name); + dev_name = resolved_dev; + } + if (! fstype) fstype = "-"; /* unknown */ @@ -537,7 +558,7 @@ get_dev (char const *disk, char const *mount_point, switch (field) { case DEV_FIELD: - cell = xstrdup (disk); + cell = dev_name; break; case TYPE_FIELD: @@ -648,7 +669,7 @@ get_disk (char const *disk) { get_dev (best_match->me_devname, best_match->me_mountdir, NULL, best_match->me_type, best_match->me_dummy, - best_match->me_remote, NULL); + best_match->me_remote, NULL, false); return true; } @@ -734,7 +755,7 @@ get_point (const char *point, const struct stat *statp) if (best_match) get_dev (best_match->me_devname, best_match->me_mountdir, point, best_match->me_type, best_match->me_dummy, best_match->me_remote, - NULL); + NULL, false); else { /* We couldn't find the mount entry corresponding to POINT. Go ahead and @@ -745,7 +766,7 @@ get_point (const char *point, const struct stat *statp) char *mp = find_mount_point (point, statp); if (mp) { - get_dev (NULL, mp, NULL, NULL, false, false, NULL); + get_dev (NULL, mp, NULL, NULL, false, false, NULL, false); free (mp); } } @@ -774,7 +795,7 @@ get_all_entries (void) for (me = mount_list; me; me = me->me_next) get_dev (me->me_devname, me->me_mountdir, NULL, me->me_type, - me->me_dummy, me->me_remote, NULL); + me->me_dummy, me->me_remote, NULL, true); } /* Add FSTYPE to the list of file system types to display. */ @@ -1066,7 +1087,7 @@ main (int argc, char **argv) { if (inode_format) grand_fsu.fsu_blocks = 1; - get_dev ("total", NULL, NULL, NULL, false, false, &grand_fsu); + get_dev ("total", NULL, NULL, NULL, false, false, &grand_fsu, false); } print_table (); -- 1.7.7.3 From debbugs-submit-bounces@debbugs.gnu.org Fri Dec 30 09:03:21 2011 Received: (at 10363) by debbugs.gnu.org; 30 Dec 2011 14:03:22 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1Rgd3I-0005JT-RM for submit@debbugs.gnu.org; Fri, 30 Dec 2011 09:03:21 -0500 Received: from mx.meyering.net ([88.168.87.75]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1Rgd3E-0005JK-Sj for 10363@debbugs.gnu.org; Fri, 30 Dec 2011 09:03:18 -0500 Received: from rho.meyering.net (localhost.localdomain [127.0.0.1]) by rho.meyering.net (Acme Bit-Twister) with ESMTP id 4DBB06009F; Fri, 30 Dec 2011 15:00:20 +0100 (CET) From: Jim Meyering To: =?iso-8859-1?Q?P=E1draig?= Brady Subject: Re: bug#10363: df vs. long-named /dev/disk/by-uuid/... file system device names In-Reply-To: <4EFC8F00.4000008@draigBrady.com> (=?iso-8859-1?Q?=22P=E1drai?= =?iso-8859-1?Q?g?= Brady"'s message of "Thu, 29 Dec 2011 16:02:08 +0000") References: <874nwpzdo5.fsf_-_@jidanni.org> <87ty4jcvwg.fsf@rho.meyering.net> <4EFC8F00.4000008@draigBrady.com> Date: Fri, 30 Dec 2011 15:00:20 +0100 Message-ID: <87wr9e9n2j.fsf@rho.meyering.net> Lines: 65 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -2.7 (--) X-Debbugs-Envelope-To: 10363 Cc: 10363@debbugs.gnu.org, coreutils@gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.7 (--) P=E1draig Brady wrote: > On 12/29/2011 02:09 PM, Jim Meyering wrote: >> On systems with recent kernel/tools, a symlink from /etc/mtab to >> /proc/mounts, and a by-UUID mount (i.e., soon, nearly everyone), >> you will see something like the following when running "df -hT": >> >> Filesystem Type Size Used Avail Use% Mounted on >> rootfs rootfs 11G 1.9G 8.0G 19% / >> /dev/disk/by-uuid/828fc648-9f30-43d8-a0b1-f7096a2edb66 ext4 11G >> 1.9G 8.0G 19% / > > Ouch. > > BTW, this is the first mail I've gotten about 10363? The first message I received had these headers: X-Debbugs-Original-Cc: 653073@bugs.debian.org, bug-coreutils@gnu.org From: jidanni@jidanni.org References: <20111224164832.GT5437@codelibre.net> Date: Sun, 25 Dec 2011 08:40:42 +0800 Message-ID: <874nwpzdo5.fsf_-_@jidanni.org> Cc: 653073@bugs.debian.org, 10363@debbugs.gnu.org X-BeenThere: bug-coreutils@gnu.org > I guess this is the right thing to do. > I.E. have higher level paths in /proc/mounts, allowing > tools that require lower level paths to traverse the links > and pick the appropriate one. > > The highest level path needs to be available to do this, > so I suppose this is appropriate in /proc/mounts, > even though it might not be the most appropriate for > human consumption, as can be seen above. > > The patch looks good. > I guess "9" is the only questionable bit. > On my Fedora 16 system I have in /proc/mounts: > > /dev/mapper/vg_tp1-lv_root ...... / > > That's a fairly informative name, whereas the links further Good point. I've just posted a revision that replaces only /dev/disk/by-uuid/... symlin= ks. > resolve to a fairly generic: > > /dev/dm-2 > > Hmm, I was contemplating using the old wrap limit of 19, > but apart from not handling the above, using a width > is inconsistent. Perhaps it's better to always resolve? I'd rather keep this minimal, since it changes the default. Dereferencing all device symlinks seems like a job for a new option, assuming there's sufficient justification. > I.E. always print the base device. It seems that one > can work back from this anyway: > > $ findmnt --source /dev/dm-2 > TARGET SOURCE FSTYPE OPTIONS > / /dev/mapper/vg_tp1-lv_root ext4 rw,relatime,... From debbugs-submit-bounces@debbugs.gnu.org Sat Dec 31 16:19:32 2011 Received: (at 10363) by debbugs.gnu.org; 31 Dec 2011 21:19:32 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1Rh6Kx-0002jy-OS for submit@debbugs.gnu.org; Sat, 31 Dec 2011 16:19:32 -0500 Received: from quechua.inka.de ([193.197.184.2] helo=mail.inka.de) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RgKla-00017y-C6 for 10363@debbugs.gnu.org; Thu, 29 Dec 2011 13:31:51 -0500 Received: from bigred.inka.de (uucp@) by mail.inka.de with local-bsmtp id 1RgKim-0003ER-6U; Thu, 29 Dec 2011 19:28:56 +0100 Received: from localhost by bigred.inka.de with local id 1RgKih-00041L-Ec; Thu, 29 Dec 2011 19:28:51 +0100 Date: Thu, 29 Dec 2011 19:28:51 +0100 To: debian-devel@lists.debian.org Subject: Re: bug#10363: /etc/mtab -> /proc/mounts symlink affects df(1) output for References: <874nwpzdo5.fsf_-_@jidanni.org> <20111226232705.29921.qmail@kosh.dhis.org> Organization: private Linux site, southern Germany MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit From: Olaf Titz Message-ID: X-Spam-Score: -2.6 (--) X-Debbugs-Envelope-To: 10363 X-Mailman-Approved-At: Sat, 31 Dec 2011 16:19:30 -0500 Cc: 653073@bugs.debian.org, rleigh@codelibre.net, 10363@debbugs.gnu.org, jidanni@jidanni.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.6 (--) > So this is a special case of a general problem with no easy solution: What > should df do when 2 filesystems are mounted at the same location? It can't > easily give correct information for both of them, since the later mount > obscures the earlier mount from view. It is a special case of an even more general problem, that mtab or /proc/self/mounts and therefore mount(8), df(1) etc. only represent the linear path where a filesystem was mounted at the time it was mounted, not the underlying tree structure. What happens with the following sequences, assuming / is the only mounted filesystem: mkdir /mnt/p1 mount /dev/sde1 /mnt/p1 mkdir /mnt/p1/p2 mount /dev/sdh1 /mnt/p1/p2 versus mkdir -p /mnt/p1/p2 mount /dev/sdh1 /mnt/p1/p2 mount /dev/sde1 /mnt/p1 not that that would be very useful, but in general it is possible. In the second case the filesystem on sdh1 is completely invisible, yet mtab and /proc/mounts in both cases contain something like /dev/sde1 /mnt/p1 ... /dev/sdh1 /mnt/p1/p2 ... only in different order: the last mounted filesystem comes last. This way df(1) should already be able to just hide any obscured filesystem: it could make two passes over the mount list, remembering every mount point and if a later mount point is equal or a parent of an earlier one (which can be determined by a simple string compare), mark the earlier one as invisible. Then in the second pass over the list output the remaining mounts. Remains the question whether this is correct in all cases and actually desirable behaviour. I think the latter is true, because df(1) output is just a snapshot of how the system looks like to a newly created process, and a newly created process can't access the obscured filesystems at all. (The fact that /proc/mounts is a symlink to /proc/self/mounts hints in the same direction.) If what's really wanted is the status of all mounted filesystems whether visible or not, I fear this can't be done without kernel help, because exactly by the "snapshot as seen by a new process" nature you don't get a handle to statfs() from the obscured parts. They can be found by looking in /sys/block or /proc/diskstats but there doesn't seem to be useful info, perhaps just another sysfs file containing the statfs() output would already suffice. Or perhaps just propose that one of the three nearly-identical /proc/self/mount* files get two additional columns with the info df(1) needs... Olaf From debbugs-submit-bounces@debbugs.gnu.org Mon Jan 02 12:37:38 2012 Received: (at 10363) by debbugs.gnu.org; 2 Jan 2012 17:37:38 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RhlpK-0001bg-8M for submit@debbugs.gnu.org; Mon, 02 Jan 2012 12:37:38 -0500 Received: from mx.meyering.net ([88.168.87.75]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RhlpH-0001bZ-NG for 10363@debbugs.gnu.org; Mon, 02 Jan 2012 12:37:36 -0500 Received: from rho.meyering.net (localhost.localdomain [127.0.0.1]) by rho.meyering.net (Acme Bit-Twister) with ESMTP id 037F6600A0; Mon, 2 Jan 2012 18:34:20 +0100 (CET) From: Jim Meyering To: Paul Eggert Subject: Re: bug#10363: df vs. long-named /dev/disk/by-uuid/... file system device names In-Reply-To: <8739c2b20i.fsf@rho.meyering.net> (Jim Meyering's message of "Fri, 30 Dec 2011 14:52:13 +0100") References: <874nwpzdo5.fsf_-_@jidanni.org> <87ty4jcvwg.fsf@rho.meyering.net> <4EFC9AF2.305@cs.ucla.edu> <8739c2b20i.fsf@rho.meyering.net> Date: Mon, 02 Jan 2012 18:34:20 +0100 Message-ID: <87lipqt3dv.fsf@rho.meyering.net> Lines: 52 MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -2.7 (--) X-Debbugs-Envelope-To: 10363 Cc: 10363@debbugs.gnu.org, coreutils@gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.7 (--) Jim Meyering wrote: ... > + char *dev_name = xstrdup (disk); > + char *resolved_dev; > + > + /* On some systems, dev_name is a long-named symlink like > + /dev/disk/by-uuid/828fc648-9f30-43d8-a0b1-f7196a2edb66 pointing > + to a much shorter and more useful name like /dev/sda1. > + When process_all is true and dev_name is a symlink whose name starts > + with /dev/disk/by-uuid/ use the resolved name instead. */ > + if (process_all > + && STRPREFIX (dev_name, "/dev/disk/by-uuid/") > + && (resolved_dev = canonicalize_filename_mode (dev_name, CAN_EXISTING))) > + { > + free (dev_name); > + dev_name = resolved_dev; > + } I noticed that there is a similar problem on any recent system with an encrypted root partition. In that case, the kernel is booted with an argument like this root=/dev/mapper/luks-88888888-8888-8888-8888-888888888888 and that same name appears in /proc/mounts and thus, even with the proposed patch, in df's "Filesystem" column. The knee-jerk reaction is to do this: if (process_all && (STRPREFIX (dev_name, "/dev/disk/by-uuid/") || STRPREFIX (dev_name, "/dev/mapper/luks-")) && (resolved_dev = canonicalize_filename_mode (dev_name, CAN_EXISTING))) but will the prefix always be spelled that way? Now, I'm thinking about making this a little more future-proof by matching the UUID part /[0-9a-fA-F-]{36}$/ instead. I.e., testing something like this: if (process_all && has_uuid_suffix (dev_name) && (resolved_dev = canonicalize_filename_mode (dev_name, CAN_EXISTING))) using this new function: static bool has_uuid_suffix (char const *s) { size_t len = strlen (s); return (36 < len && strspn (s + len - 36, "-0123456789abcdefABCDEF") == 36); } From debbugs-submit-bounces@debbugs.gnu.org Mon Jan 02 14:30:38 2012 Received: (at 10363) by debbugs.gnu.org; 2 Jan 2012 19:30:38 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1Rhnag-0004Ir-Hs for submit@debbugs.gnu.org; Mon, 02 Jan 2012 14:30:38 -0500 Received: from mail1.vodafone.ie ([213.233.128.43]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1Rhnae-0004Ij-FF for 10363@debbugs.gnu.org; Mon, 02 Jan 2012 14:30:37 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Ar0SAGkEAk9tTeHd/2dsb2JhbAAMN4IFqBqFMAEBAQQyAUYQCw0LCRYPCQMCAQIBRQYNAQcBAbwkjA8EmnGMRQ Received: from unknown (HELO [192.168.1.79]) ([109.77.225.221]) by mail1.vodafone.ie with ESMTP; 02 Jan 2012 19:27:21 +0000 Message-ID: <4F020518.6070701@draigBrady.com> Date: Mon, 02 Jan 2012 19:27:20 +0000 From: =?ISO-8859-1?Q?P=E1draig_Brady?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:6.0) Gecko/20110816 Thunderbird/6.0 MIME-Version: 1.0 To: Jim Meyering Subject: Re: bug#10363: df vs. long-named /dev/disk/by-uuid/... file system device names References: <874nwpzdo5.fsf_-_@jidanni.org> <87ty4jcvwg.fsf@rho.meyering.net> <4EFC9AF2.305@cs.ucla.edu> <8739c2b20i.fsf@rho.meyering.net> <87lipqt3dv.fsf@rho.meyering.net> In-Reply-To: <87lipqt3dv.fsf@rho.meyering.net> X-Enigmail-Version: 1.3.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.5 (--) X-Debbugs-Envelope-To: 10363 Cc: Paul Eggert , 10363@debbugs.gnu.org, coreutils@gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.5 (--) On 01/02/2012 05:34 PM, Jim Meyering wrote: > Jim Meyering wrote: > ... >> + char *dev_name = xstrdup (disk); >> + char *resolved_dev; >> + >> + /* On some systems, dev_name is a long-named symlink like >> + /dev/disk/by-uuid/828fc648-9f30-43d8-a0b1-f7196a2edb66 pointing >> + to a much shorter and more useful name like /dev/sda1. >> + When process_all is true and dev_name is a symlink whose name starts >> + with /dev/disk/by-uuid/ use the resolved name instead. */ >> + if (process_all >> + && STRPREFIX (dev_name, "/dev/disk/by-uuid/") >> + && (resolved_dev = canonicalize_filename_mode (dev_name, CAN_EXISTING))) >> + { >> + free (dev_name); >> + dev_name = resolved_dev; >> + } > > I noticed that there is a similar problem on any recent > system with an encrypted root partition. > In that case, the kernel is booted with an argument like this > > root=/dev/mapper/luks-88888888-8888-8888-8888-888888888888 > > and that same name appears in /proc/mounts and thus, even with > the proposed patch, in df's "Filesystem" column. The knee-jerk > reaction is to do this: > > if (process_all > && (STRPREFIX (dev_name, "/dev/disk/by-uuid/") > || STRPREFIX (dev_name, "/dev/mapper/luks-")) > && (resolved_dev = canonicalize_filename_mode (dev_name, CAN_EXISTING))) > > but will the prefix always be spelled that way? > > Now, I'm thinking about making this a little more future-proof by > matching the UUID part /[0-9a-fA-F-]{36}$/ instead. > I.e., testing something like this: > > if (process_all > && has_uuid_suffix (dev_name) > && (resolved_dev = canonicalize_filename_mode (dev_name, CAN_EXISTING))) > > using this new function: > > static bool > has_uuid_suffix (char const *s) > { > size_t len = strlen (s); > return (36 < len > && strspn (s + len - 36, "-0123456789abcdefABCDEF") == 36); > } Yes that's awkward but warranted. The logic looks correct. This is assuming of course that UUIDs are the only "high level" form presented in /proc/mounts that one doesn't want displayed. I can't think of anything else worth avoiding at the moment. cheers, Pádraig. From debbugs-submit-bounces@debbugs.gnu.org Mon Jan 02 16:15:55 2012 Received: (at 10363) by debbugs.gnu.org; 2 Jan 2012 21:15:55 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RhpEX-0006ku-A6 for submit@debbugs.gnu.org; Mon, 02 Jan 2012 16:15:54 -0500 Received: from mx.meyering.net ([88.168.87.75]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1RhpER-0006ki-P6 for 10363@debbugs.gnu.org; Mon, 02 Jan 2012 16:15:51 -0500 Received: from rho.meyering.net (localhost.localdomain [127.0.0.1]) by rho.meyering.net (Acme Bit-Twister) with ESMTP id 31648604C2; Mon, 2 Jan 2012 22:12:32 +0100 (CET) From: Jim Meyering To: =?iso-8859-1?Q?P=E1draig?= Brady Subject: Re: bug#10363: df vs. long-named /dev/disk/by-uuid/... file system device names In-Reply-To: <4F020518.6070701@draigBrady.com> (=?iso-8859-1?Q?=22P=E1drai?= =?iso-8859-1?Q?g?= Brady"'s message of "Mon, 02 Jan 2012 19:27:20 +0000") References: <874nwpzdo5.fsf_-_@jidanni.org> <87ty4jcvwg.fsf@rho.meyering.net> <4EFC9AF2.305@cs.ucla.edu> <8739c2b20i.fsf@rho.meyering.net> <87lipqt3dv.fsf@rho.meyering.net> <4F020518.6070701@draigBrady.com> Date: Mon, 02 Jan 2012 22:12:32 +0100 Message-ID: <8762gtsta7.fsf@rho.meyering.net> Lines: 222 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -2.7 (--) X-Debbugs-Envelope-To: 10363 Cc: Paul Eggert , 10363@debbugs.gnu.org, coreutils@gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.7 (--) P=E1draig Brady wrote: ... >> Now, I'm thinking about making this a little more future-proof by >> matching the UUID part /[0-9a-fA-F-]{36}$/ instead. >> I.e., testing something like this: >> >> if (process_all >> && has_uuid_suffix (dev_name) >> && (resolved_dev =3D canonicalize_filename_mode (dev_name, CAN_= EXISTING))) >> >> using this new function: >> >> static bool >> has_uuid_suffix (char const *s) >> { >> size_t len =3D strlen (s); >> return (36 < len >> && strspn (s + len - 36, "-0123456789abcdefABCDEF") =3D=3D 3= 6); >> } > > Yes that's awkward but warranted. > The logic looks correct. > > This is assuming of course that UUIDs are the only "high level" form > presented in /proc/mounts that one doesn't want displayed. > I can't think of anything else worth avoiding at the moment. Thanks for the review. Here's an updated patch. Changes: - added comment for new function - added _GL_ATTRIBUTE_PURE, too - updated commit log and comments >From b30f021ada261e8b248f7040f8c98db6495e9e88 Mon Sep 17 00:00:00 2001 From: Jim Meyering Date: Thu, 29 Dec 2011 14:49:00 +0100 Subject: [PATCH] df: work around long-named /dev/disk/by-uuid/... symlinks On systems with recent kernel/tools, a symlink from /etc/mtab to /proc/mounts, and a by-UUID mount (i.e., soon, nearly everyone), you will see something like the following when running "df -hT": (this has been truncated to fit in a width-limited ChangeLog file) Filesystem Type Siz... rootfs rootfs 11G udev devtmpfs 3.8G tmpfs tmpfs 774M /dev/disk/by-uuid/828fc648-9f30-43d8-a0b1-f7096a2edb66 ext4 11G tmpfs tmpfs 1.6G /dev/sda2 ext3 494M /dev/sda5 ext4 12G /dev/sda6 ext4 9.9G Contrast that with what we're used to seeing (modulo the two entries mounted on "/", which is a separate problem): Filesystem Type Size Used Avail Use% Mounted on rootfs rootfs 11G 1.9G 8.0G 19% / udev devtmpfs 3.8G 0 3.8G 0% /dev tmpfs tmpfs 774M 376K 774M 1% /run /dev/sda3 ext4 11G 1.9G 8.0G 19% / tmpfs tmpfs 1.6G 8.0K 1.6G 1% /run/shm /dev/sda2 ext3 494M 78M 392M 17% /boot /dev/sda5 ext4 12G 7.6G 3.7G 68% /usr /dev/sda6 ext4 9.9G 6.6G 2.8G 71% /var When that long /dev/disk/by-uuid/... name is merely a symlink to a much shorter (and often more useful) device name like "/dev/sda3", and when it's part of a listing of all file systems, I would much prefer to see only the latter. Similarly, when using an encrypted root file system, you would see a name like /dev/mapper/luks-828fc648-9f30-43d8-a0b1-f7196a2edb66 pointing to say, /dev/dm-0, I prefer the shorter name. I.e., if I explicitly run "df -hT /dev/disk/by-uuid/828fc648-9f30-43d8-a0b1-f7096a2edb66", then, it's fine -- and expected -- to print to the long name. It was explicitly given. However, with no non-option argument, df should print the shorter name. Note that performing this translation at a lower level (via a change to gnulib's mountlist.c) would make it impossible to distinguish those two cases. * src/df.c: Include "canonicalize.h". (get_dev): Add a parameter, telling when we're in process-all- mount-points mode; update all callers. When true, resolve UUID-suffixed symlinks. Reported by Dan Jacobson in http://bugs.gnu.org/10363 --- src/df.c | 49 +++++++++++++++++++++++++++++++++++++++++-------- 1 files changed, 41 insertions(+), 8 deletions(-) diff --git a/src/df.c b/src/df.c index 9677687..fae32cd 100644 --- a/src/df.c +++ b/src/df.c @@ -25,6 +25,7 @@ #include #include "system.h" +#include "canonicalize.h" #include "error.h" #include "fsusage.h" #include "human.h" @@ -417,6 +418,17 @@ add_uint_with_neg_flag (uintmax_t *dest, bool *dest_ne= g, *dest =3D -*dest; } +/* Return true if S ends in a string that may be a 36-byte UUID, + i.e., of the form HHHHHHHH-HHHH-HHHH-HHHH-HHHHHHHHHHHH, where + each H is an upper or lower case hexadecimal digit. */ +static bool _GL_ATTRIBUTE_PURE +has_uuid_suffix (char const *s) +{ + size_t len =3D strlen (s); + return (36 < len + && strspn (s + len - 36, "-0123456789abcdefABCDEF") =3D=3D 36); +} + /* Obtain a space listing for the disk device with absolute file name DISK. If MOUNT_POINT is non-NULL, it is the name of the root of the file system on DISK. @@ -428,13 +440,16 @@ add_uint_with_neg_flag (uintmax_t *dest, bool *dest_n= eg, If FSTYPE is non-NULL, it is the type of the file system on DISK. If MOUNT_POINT is non-NULL, then DISK may be NULL -- certain systems may not be able to produce statistics in this case. - ME_DUMMY and ME_REMOTE are the mount entry flags. */ + ME_DUMMY and ME_REMOTE are the mount entry flags. + Caller must set PROCESS_ALL to true when iterating over all entries, as + when df is invoked with no non-option argument. See below for details.= */ static void get_dev (char const *disk, char const *mount_point, char const *stat_file, char const *fstype, bool me_dummy, bool me_remote, - const struct fs_usage *force_fsu) + const struct fs_usage *force_fsu, + bool process_all) { struct fs_usage fsu; char buf[LONGEST_HUMAN_READABLE + 2]; @@ -488,6 +503,24 @@ get_dev (char const *disk, char const *mount_point, if (! disk) disk =3D "-"; /* unknown */ + + char *dev_name =3D xstrdup (disk); + char *resolved_dev; + + /* On some systems, dev_name is a long-named symlink like + /dev/disk/by-uuid/828fc648-9f30-43d8-a0b1-f7196a2edb66 pointing to a + much shorter and more useful name like /dev/sda1. It may also look + like /dev/mapper/luks-828fc648-9f30-43d8-a0b1-f7196a2edb66 and point = to + /dev/dm-0. When process_all is true and dev_name is a symlink whose + name ends with a UUID use the resolved name instead. */ + if (process_all + && has_uuid_suffix (dev_name) + && (resolved_dev =3D canonicalize_filename_mode (dev_name, CAN_EXIST= ING))) + { + free (dev_name); + dev_name =3D resolved_dev; + } + if (! fstype) fstype =3D "-"; /* unknown */ @@ -537,7 +570,7 @@ get_dev (char const *disk, char const *mount_point, switch (field) { case DEV_FIELD: - cell =3D xstrdup (disk); + cell =3D dev_name; break; case TYPE_FIELD: @@ -648,7 +681,7 @@ get_disk (char const *disk) { get_dev (best_match->me_devname, best_match->me_mountdir, NULL, best_match->me_type, best_match->me_dummy, - best_match->me_remote, NULL); + best_match->me_remote, NULL, false); return true; } @@ -734,7 +767,7 @@ get_point (const char *point, const struct stat *statp) if (best_match) get_dev (best_match->me_devname, best_match->me_mountdir, point, best_match->me_type, best_match->me_dummy, best_match->me_rem= ote, - NULL); + NULL, false); else { /* We couldn't find the mount entry corresponding to POINT. Go ahea= d and @@ -745,7 +778,7 @@ get_point (const char *point, const struct stat *statp) char *mp =3D find_mount_point (point, statp); if (mp) { - get_dev (NULL, mp, NULL, NULL, false, false, NULL); + get_dev (NULL, mp, NULL, NULL, false, false, NULL, false); free (mp); } } @@ -774,7 +807,7 @@ get_all_entries (void) for (me =3D mount_list; me; me =3D me->me_next) get_dev (me->me_devname, me->me_mountdir, NULL, me->me_type, - me->me_dummy, me->me_remote, NULL); + me->me_dummy, me->me_remote, NULL, true); } /* Add FSTYPE to the list of file system types to display. */ @@ -1066,7 +1099,7 @@ main (int argc, char **argv) { if (inode_format) grand_fsu.fsu_blocks =3D 1; - get_dev ("total", NULL, NULL, NULL, false, false, &grand_fsu); + get_dev ("total", NULL, NULL, NULL, false, false, &grand_fsu, false); } print_table (); -- 1.7.8.1.391.g2c2ad From debbugs-submit-bounces@debbugs.gnu.org Tue Jan 03 11:01:35 2012 Received: (at 10363) by debbugs.gnu.org; 3 Jan 2012 16:01:35 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1Ri6nu-0002I5-9P for submit@debbugs.gnu.org; Tue, 03 Jan 2012 11:01:35 -0500 Received: from mx.meyering.net ([88.168.87.75]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1Ri6nr-0002Hw-I0 for 10363@debbugs.gnu.org; Tue, 03 Jan 2012 11:01:33 -0500 Received: from rho.meyering.net (localhost.localdomain [127.0.0.1]) by rho.meyering.net (Acme Bit-Twister) with ESMTP id 568586001B; Tue, 3 Jan 2012 16:58:11 +0100 (CET) From: Jim Meyering To: =?iso-8859-1?Q?P=E1draig?= Brady Subject: Re: bug#10363: df vs. long-named /dev/disk/by-uuid/... file system device names In-Reply-To: <8762gtsta7.fsf@rho.meyering.net> (Jim Meyering's message of "Mon, 02 Jan 2012 22:12:32 +0100") References: <874nwpzdo5.fsf_-_@jidanni.org> <87ty4jcvwg.fsf@rho.meyering.net> <4EFC9AF2.305@cs.ucla.edu> <8739c2b20i.fsf@rho.meyering.net> <87lipqt3dv.fsf@rho.meyering.net> <4F020518.6070701@draigBrady.com> <8762gtsta7.fsf@rho.meyering.net> Date: Tue, 03 Jan 2012 16:58:11 +0100 Message-ID: <8739bwlqwc.fsf@rho.meyering.net> Lines: 249 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -2.7 (--) X-Debbugs-Envelope-To: 10363 Cc: Paul Eggert , 10363@debbugs.gnu.org, coreutils@gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.7 (--) Jim Meyering wrote: > P=E1draig Brady wrote: > ... >>> Now, I'm thinking about making this a little more future-proof by >>> matching the UUID part /[0-9a-fA-F-]{36}$/ instead. >>> I.e., testing something like this: >>> >>> if (process_all >>> && has_uuid_suffix (dev_name) >>> && (resolved_dev =3D canonicalize_filename_mode (dev_name, CAN= _EXISTING))) >>> >>> using this new function: >>> >>> static bool >>> has_uuid_suffix (char const *s) >>> { >>> size_t len =3D strlen (s); >>> return (36 < len >>> && strspn (s + len - 36, "-0123456789abcdefABCDEF") =3D=3D = 36); >>> } >> >> Yes that's awkward but warranted. >> The logic looks correct. >> >> This is assuming of course that UUIDs are the only "high level" form >> presented in /proc/mounts that one doesn't want displayed. >> I can't think of anything else worth avoiding at the moment. > > Thanks for the review. > Here's an updated patch. > Changes: > - added comment for new function > - added _GL_ATTRIBUTE_PURE, too > - updated commit log and comments > >>>From b30f021ada261e8b248f7040f8c98db6495e9e88 Mon Sep 17 00:00:00 2001 > From: Jim Meyering > Date: Thu, 29 Dec 2011 14:49:00 +0100 > Subject: [PATCH] df: work around long-named /dev/disk/by-uuid/... symlinks I've added a NEWS entry: >From 1e18d8416f9ef43bf08982cabe54220587061a08 Mon Sep 17 00:00:00 2001 From: Jim Meyering Date: Thu, 29 Dec 2011 14:49:00 +0100 Subject: [PATCH] df: work around long-named /dev/disk/by-uuid/... symlinks On systems with recent kernel/tools, a symlink from /etc/mtab to /proc/mounts, and a by-UUID mount (i.e., soon, nearly everyone), you will see something like the following when running "df -hT": (this has been truncated to fit in a width-limited ChangeLog file) Filesystem Type Siz... rootfs rootfs 11G udev devtmpfs 3.8G tmpfs tmpfs 774M /dev/disk/by-uuid/828fc648-9f30-43d8-a0b1-f7096a2edb66 ext4 11G tmpfs tmpfs 1.6G /dev/sda2 ext3 494M /dev/sda5 ext4 12G /dev/sda6 ext4 9.9G Contrast that with what we're used to seeing (modulo the two entries mounted on "/", which is a separate problem): Filesystem Type Size Used Avail Use% Mounted on rootfs rootfs 11G 1.9G 8.0G 19% / udev devtmpfs 3.8G 0 3.8G 0% /dev tmpfs tmpfs 774M 376K 774M 1% /run /dev/sda3 ext4 11G 1.9G 8.0G 19% / tmpfs tmpfs 1.6G 8.0K 1.6G 1% /run/shm /dev/sda2 ext3 494M 78M 392M 17% /boot /dev/sda5 ext4 12G 7.6G 3.7G 68% /usr /dev/sda6 ext4 9.9G 6.6G 2.8G 71% /var When that long /dev/disk/by-uuid/... name is merely a symlink to a much shorter (and often more useful) device name like "/dev/sda3", and when it's part of a listing of all file systems, I would much prefer to see only the latter. Similarly, when using an encrypted root file system, you would see a name like /dev/mapper/luks-828fc648-9f30-43d8-a0b1-f7196a2edb66 pointing to say, /dev/dm-0, I prefer the shorter name. I.e., if I explicitly run "df -hT /dev/disk/by-uuid/828fc648-9f30-43d8-a0b1-f7096a2edb66", then, it's fine -- and expected -- to print to the long name. It was explicitly given. However, with no non-option argument, df should print the shorter name. Note that performing this translation at a lower level (via a change to gnulib's mountlist.c) would make it impossible to distinguish those two cases. * src/df.c: Include "canonicalize.h". (get_dev): Add a parameter, telling when we're in process-all- mount-points mode; update all callers. When true, resolve UUID-suffixed symlinks. * NEWS (Changes in behavior): Mention it. Reported by Dan Jacobson in http://bugs.gnu.org/10363 --- NEWS | 5 +++++ src/df.c | 49 +++++++++++++++++++++++++++++++++++++++++-------- 2 files changed, 46 insertions(+), 8 deletions(-) diff --git a/NEWS b/NEWS index 78a90b6..bc5a0a9 100644 --- a/NEWS +++ b/NEWS @@ -36,6 +36,11 @@ GNU coreutils NEWS -*= - outline -*- ** Changes in behavior + df, with no non-option argument and recent enough kernel/tools, would + print a long UUID-including file system name, pushing second and subsequ= ent + columns far to the right. Now, when that long name refers to a symlink, + df prints the usually-short referent instead. + tail -f now uses polling (not inotify) when any of its file arguments resides on a file system of unknown type. In addition, for each such argument, tail -f prints a warning with the FS type magic number and a diff --git a/src/df.c b/src/df.c index 9677687..fae32cd 100644 --- a/src/df.c +++ b/src/df.c @@ -25,6 +25,7 @@ #include #include "system.h" +#include "canonicalize.h" #include "error.h" #include "fsusage.h" #include "human.h" @@ -417,6 +418,17 @@ add_uint_with_neg_flag (uintmax_t *dest, bool *dest_ne= g, *dest =3D -*dest; } +/* Return true if S ends in a string that may be a 36-byte UUID, + i.e., of the form HHHHHHHH-HHHH-HHHH-HHHH-HHHHHHHHHHHH, where + each H is an upper or lower case hexadecimal digit. */ +static bool _GL_ATTRIBUTE_PURE +has_uuid_suffix (char const *s) +{ + size_t len =3D strlen (s); + return (36 < len + && strspn (s + len - 36, "-0123456789abcdefABCDEF") =3D=3D 36); +} + /* Obtain a space listing for the disk device with absolute file name DISK. If MOUNT_POINT is non-NULL, it is the name of the root of the file system on DISK. @@ -428,13 +440,16 @@ add_uint_with_neg_flag (uintmax_t *dest, bool *dest_n= eg, If FSTYPE is non-NULL, it is the type of the file system on DISK. If MOUNT_POINT is non-NULL, then DISK may be NULL -- certain systems may not be able to produce statistics in this case. - ME_DUMMY and ME_REMOTE are the mount entry flags. */ + ME_DUMMY and ME_REMOTE are the mount entry flags. + Caller must set PROCESS_ALL to true when iterating over all entries, as + when df is invoked with no non-option argument. See below for details.= */ static void get_dev (char const *disk, char const *mount_point, char const *stat_file, char const *fstype, bool me_dummy, bool me_remote, - const struct fs_usage *force_fsu) + const struct fs_usage *force_fsu, + bool process_all) { struct fs_usage fsu; char buf[LONGEST_HUMAN_READABLE + 2]; @@ -488,6 +503,24 @@ get_dev (char const *disk, char const *mount_point, if (! disk) disk =3D "-"; /* unknown */ + + char *dev_name =3D xstrdup (disk); + char *resolved_dev; + + /* On some systems, dev_name is a long-named symlink like + /dev/disk/by-uuid/828fc648-9f30-43d8-a0b1-f7196a2edb66 pointing to a + much shorter and more useful name like /dev/sda1. It may also look + like /dev/mapper/luks-828fc648-9f30-43d8-a0b1-f7196a2edb66 and point = to + /dev/dm-0. When process_all is true and dev_name is a symlink whose + name ends with a UUID use the resolved name instead. */ + if (process_all + && has_uuid_suffix (dev_name) + && (resolved_dev =3D canonicalize_filename_mode (dev_name, CAN_EXIST= ING))) + { + free (dev_name); + dev_name =3D resolved_dev; + } + if (! fstype) fstype =3D "-"; /* unknown */ @@ -537,7 +570,7 @@ get_dev (char const *disk, char const *mount_point, switch (field) { case DEV_FIELD: - cell =3D xstrdup (disk); + cell =3D dev_name; break; case TYPE_FIELD: @@ -648,7 +681,7 @@ get_disk (char const *disk) { get_dev (best_match->me_devname, best_match->me_mountdir, NULL, best_match->me_type, best_match->me_dummy, - best_match->me_remote, NULL); + best_match->me_remote, NULL, false); return true; } @@ -734,7 +767,7 @@ get_point (const char *point, const struct stat *statp) if (best_match) get_dev (best_match->me_devname, best_match->me_mountdir, point, best_match->me_type, best_match->me_dummy, best_match->me_rem= ote, - NULL); + NULL, false); else { /* We couldn't find the mount entry corresponding to POINT. Go ahea= d and @@ -745,7 +778,7 @@ get_point (const char *point, const struct stat *statp) char *mp =3D find_mount_point (point, statp); if (mp) { - get_dev (NULL, mp, NULL, NULL, false, false, NULL); + get_dev (NULL, mp, NULL, NULL, false, false, NULL, false); free (mp); } } @@ -774,7 +807,7 @@ get_all_entries (void) for (me =3D mount_list; me; me =3D me->me_next) get_dev (me->me_devname, me->me_mountdir, NULL, me->me_type, - me->me_dummy, me->me_remote, NULL); + me->me_dummy, me->me_remote, NULL, true); } /* Add FSTYPE to the list of file system types to display. */ @@ -1066,7 +1099,7 @@ main (int argc, char **argv) { if (inode_format) grand_fsu.fsu_blocks =3D 1; - get_dev ("total", NULL, NULL, NULL, false, false, &grand_fsu); + get_dev ("total", NULL, NULL, NULL, false, false, &grand_fsu, false); } print_table (); -- 1.7.8.1.391.g2c2ad From debbugs-submit-bounces@debbugs.gnu.org Tue Jan 03 11:27:25 2012 Received: (at 10363) by debbugs.gnu.org; 3 Jan 2012 16:27:25 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1Ri7Cv-0002ss-BJ for submit@debbugs.gnu.org; Tue, 03 Jan 2012 11:27:25 -0500 Received: from mail3.vodafone.ie ([213.233.128.45]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1Ri7Ct-0002sk-Aq for 10363@debbugs.gnu.org; Tue, 03 Jan 2012 11:27:24 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: AlMFAIArA09tTBWn/2dsb2JhbAAMOIIFqCCFMgEBAQQyAUYQCw0LCRYPCQMCAQIBRQYNAQcBARa9HYwPBJpxjEU Received: from unknown (HELO [192.168.1.79]) ([109.76.21.167]) by mail3.vodafone.ie with ESMTP; 03 Jan 2012 16:23:51 +0000 Message-ID: <4F032B96.3070005@draigBrady.com> Date: Tue, 03 Jan 2012 16:23:50 +0000 From: =?ISO-8859-1?Q?P=E1draig_Brady?= User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:6.0) Gecko/20110816 Thunderbird/6.0 MIME-Version: 1.0 To: Jim Meyering Subject: Re: bug#10363: df vs. long-named /dev/disk/by-uuid/... file system device names References: <874nwpzdo5.fsf_-_@jidanni.org> <87ty4jcvwg.fsf@rho.meyering.net> <4EFC9AF2.305@cs.ucla.edu> <8739c2b20i.fsf@rho.meyering.net> <87lipqt3dv.fsf@rho.meyering.net> <4F020518.6070701@draigBrady.com> <8762gtsta7.fsf@rho.meyering.net> <8739bwlqwc.fsf@rho.meyering.net> In-Reply-To: <8739bwlqwc.fsf@rho.meyering.net> X-Enigmail-Version: 1.3.2 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.5 (--) X-Debbugs-Envelope-To: 10363 Cc: Paul Eggert , 10363@debbugs.gnu.org, coreutils@gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.5 (--) On 01/03/2012 03:58 PM, Jim Meyering wrote: > diff --git a/NEWS b/NEWS > + df, with no non-option argument and recent enough kernel/tools, would > + print a long UUID-including file system name, pushing second and subsequent > + columns far to the right. Now, when that long name refers to a symlink, > + df prints the usually-short referent instead. I would change this: s/would print a long UUID-including file system name/ could print long UUID-including file system names/ I usually try to make the first line of the NEWS entry a summary, like: df avoids long UUID-including file system names, in the default listing. On recent enough kernel/tools, these long names can be used, pushing second and subsequent columns far to the right. Now, when a long name refers to a symlink, and no file systems are specified, df prints the usually-short referent instead. cheers, Pádraig. From debbugs-submit-bounces@debbugs.gnu.org Tue Jan 03 11:29:41 2012 Received: (at 10363) by debbugs.gnu.org; 3 Jan 2012 16:29:41 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1Ri7F6-0002vx-PH for submit@debbugs.gnu.org; Tue, 03 Jan 2012 11:29:41 -0500 Received: from mx.meyering.net ([88.168.87.75]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1Ri7F4-0002vq-Oy for 10363@debbugs.gnu.org; Tue, 03 Jan 2012 11:29:39 -0500 Received: from rho.meyering.net (localhost.localdomain [127.0.0.1]) by rho.meyering.net (Acme Bit-Twister) with ESMTP id 74CD660092; Tue, 3 Jan 2012 17:26:18 +0100 (CET) From: Jim Meyering To: =?iso-8859-1?Q?P=E1draig?= Brady Subject: Re: bug#10363: df vs. long-named /dev/disk/by-uuid/... file system device names In-Reply-To: <4F032B96.3070005@draigBrady.com> (=?iso-8859-1?Q?=22P=E1drai?= =?iso-8859-1?Q?g?= Brady"'s message of "Tue, 03 Jan 2012 16:23:50 +0000") References: <874nwpzdo5.fsf_-_@jidanni.org> <87ty4jcvwg.fsf@rho.meyering.net> <4EFC9AF2.305@cs.ucla.edu> <8739c2b20i.fsf@rho.meyering.net> <87lipqt3dv.fsf@rho.meyering.net> <4F020518.6070701@draigBrady.com> <8762gtsta7.fsf@rho.meyering.net> <8739bwlqwc.fsf@rho.meyering.net> <4F032B96.3070005@draigBrady.com> Date: Tue, 03 Jan 2012 17:26:18 +0100 Message-ID: <87wr98kb11.fsf@rho.meyering.net> Lines: 24 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -2.7 (--) X-Debbugs-Envelope-To: 10363 Cc: Paul Eggert , 10363@debbugs.gnu.org, coreutils@gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.7 (--) P=E1draig Brady wrote: > On 01/03/2012 03:58 PM, Jim Meyering wrote: >> diff --git a/NEWS b/NEWS > >> + df, with no non-option argument and recent enough kernel/tools, would >> + print a long UUID-including file system name, pushing second and subs= equent >> + columns far to the right. Now, when that long name refers to a symli= nk, >> + df prints the usually-short referent instead. > > I would change this: > > s/would print a long UUID-including file system name/ > could print long UUID-including file system names/ > > I usually try to make the first line of the NEWS entry a summary, like: > > df avoids long UUID-including file system names, in the default listing. > On recent enough kernel/tools, these long names can be used, pushing seco= nd > and subsequent columns far to the right. Now, when a long name refers > to a symlink, and no file systems are specified, df prints the > usually-short referent instead. Thanks. I prefer your wording, too. Will adjust. From debbugs-submit-bounces@debbugs.gnu.org Tue Jan 03 11:39:33 2012 Received: (at 10363) by debbugs.gnu.org; 3 Jan 2012 16:39:33 +0000 Received: from localhost ([127.0.0.1] helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1Ri7Of-0003Ak-5C for submit@debbugs.gnu.org; Tue, 03 Jan 2012 11:39:33 -0500 Received: from mx.meyering.net ([88.168.87.75]) by debbugs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1Ri7Oc-0003Ab-7B for 10363@debbugs.gnu.org; Tue, 03 Jan 2012 11:39:31 -0500 Received: from rho.meyering.net (localhost.localdomain [127.0.0.1]) by rho.meyering.net (Acme Bit-Twister) with ESMTP id 21BB860092; Tue, 3 Jan 2012 17:36:10 +0100 (CET) From: Jim Meyering To: =?iso-8859-1?Q?P=E1draig?= Brady Subject: Re: bug#10363: df vs. long-named /dev/disk/by-uuid/... file system device names In-Reply-To: <4F032B96.3070005@draigBrady.com> (=?iso-8859-1?Q?=22P=E1drai?= =?iso-8859-1?Q?g?= Brady"'s message of "Tue, 03 Jan 2012 16:23:50 +0000") References: <874nwpzdo5.fsf_-_@jidanni.org> <87ty4jcvwg.fsf@rho.meyering.net> <4EFC9AF2.305@cs.ucla.edu> <8739c2b20i.fsf@rho.meyering.net> <87lipqt3dv.fsf@rho.meyering.net> <4F020518.6070701@draigBrady.com> <8762gtsta7.fsf@rho.meyering.net> <8739bwlqwc.fsf@rho.meyering.net> <4F032B96.3070005@draigBrady.com> Date: Tue, 03 Jan 2012 17:36:10 +0100 Message-ID: <87lipokakl.fsf@rho.meyering.net> Lines: 81 MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -2.7 (--) X-Debbugs-Envelope-To: 10363 Cc: Paul Eggert , 10363@debbugs.gnu.org, coreutils@gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.7 (--) P=E1draig Brady wrote: > On 01/03/2012 03:58 PM, Jim Meyering wrote: >> diff --git a/NEWS b/NEWS > >> + df, with no non-option argument and recent enough kernel/tools, would >> + print a long UUID-including file system name, pushing second and subs= equent >> + columns far to the right. Now, when that long name refers to a symli= nk, >> + df prints the usually-short referent instead. > > I would change this: > > s/would print a long UUID-including file system name/ > could print long UUID-including file system names/ > > I usually try to make the first line of the NEWS entry a summary, like: > > df avoids long UUID-including file system names, in the default listing. > On recent enough kernel/tools, these long names can be used, pushing seco= nd > and subsequent columns far to the right. Now, when a long name refers > to a symlink, and no file systems are specified, df prints the > usually-short referent instead. Thanks, modulo minor rewording: >From 2403b1caa51e59b442f80d223e4de6faecfcc5ca Mon Sep 17 00:00:00 2001 From: Jim Meyering Date: Tue, 3 Jan 2012 17:33:21 +0100 Subject: [PATCH] doc: adjust NEWS MIME-Version: 1.0 Content-Type: text/plain; charset=3DUTF-8 Content-Transfer-Encoding: 8bit * NEWS (New programs): Move this small section to the top. (df): Reword entry, from P=E1draig Brady. --- NEWS | 17 +++++++++-------- 1 files changed, 9 insertions(+), 8 deletions(-) diff --git a/NEWS b/NEWS index bc5a0a9..ed6f831 100644 --- a/NEWS +++ b/NEWS @@ -2,6 +2,10 @@ GNU coreutils NEWS -*- = outline -*- * Noteworthy changes in release ?.? (????-??-??) [?] +** New programs + + realpath: print resolved file names. + ** Bug fixes du -x no longer counts root directories of other file systems. @@ -36,20 +40,17 @@ GNU coreutils NEWS -= *- outline -*- ** Changes in behavior - df, with no non-option argument and recent enough kernel/tools, would - print a long UUID-including file system name, pushing second and subsequ= ent - columns far to the right. Now, when that long name refers to a symlink, - df prints the usually-short referent instead. + df avoids long UUID-including file system names in the default listing. + With recent enough kernel/tools, these long names would be used, pushing + second and subsequent columns far to the right. Now, when a long name + refers to a symlink, and no file systems are specified, df prints the + usually-short referent instead. tail -f now uses polling (not inotify) when any of its file arguments resides on a file system of unknown type. In addition, for each such argument, tail -f prints a warning with the FS type magic number and a request to report it to the bug-reporting address. -** New programs - - realpath: print resolved file names. - * Noteworthy changes in release 8.14 (2011-10-12) [stable] -- 1.7.8.1.391.g2c2ad From debbugs-submit-bounces@debbugs.gnu.org Wed Jan 18 09:26:31 2012 Received: (at 10363) by debbugs.gnu.org; 18 Jan 2012 14:26:32 +0000 Received: from localhost ([127.0.0.1]:34224 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1RnWT8-000475-PZ for submit@debbugs.gnu.org; Wed, 18 Jan 2012 09:26:31 -0500 Received: from fmmailgate02.web.de ([217.72.192.227]:46657) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1RnWSz-00046j-GE for 10363@debbugs.gnu.org; Wed, 18 Jan 2012 09:26:28 -0500 Received: from moweb001.kundenserver.de (moweb001.kundenserver.de [172.19.20.114]) by fmmailgate02.web.de (Postfix) with ESMTP id 41B801BFE2B54 for <10363@debbugs.gnu.org>; Wed, 18 Jan 2012 15:25:13 +0100 (CET) Received: from frosties.localnet ([95.208.118.96]) by smtp.web.de (mrweb002) with ESMTPA (Nemesis) id 0M1noI-1SfllL3l8s-00t1zc; Wed, 18 Jan 2012 15:25:06 +0100 Received: from mrvn by frosties.localnet with local (Exim 4.77) (envelope-from ) id 1RnWRl-0000Js-6X; Wed, 18 Jan 2012 15:25:05 +0100 From: Goswin von Brederlow To: "Alan Curry" Subject: Re: bug#10363: /etc/mtab -> /proc/mounts symlink affects df(1) output for References: <20111226232705.29921.qmail@kosh.dhis.org> Date: Wed, 18 Jan 2012 15:25:05 +0100 In-Reply-To: <20111226232705.29921.qmail@kosh.dhis.org> (Alan Curry's message of "Mon, 26 Dec 2011 18:27:05 -0500 (GMT+5)") Message-ID: <87k44p9jge.fsf@frosties.localnet> User-Agent: Gnus/5.110009 (No Gnus v0.9) XEmacs/21.4.22 (linux, no MULE) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Provags-ID: V02:K0:ljgZnGQEsNrSB2mFHz/+40bQ28ZJDbY8yjeB6HtjT8r d1K3SmCBf/uO4VDoO3EXYwGK2lwmm3otZkeIwRvHD7Rb8gLPD2 pwgjrNVFxM+GjNJ7v+HUWOeawrG2ypsfuYyHwCuETxnUETcgqC kkdLuvOkmYtJjmBcPAazXL/B3SuXM+AeksSdzNBhzUN2VJ1q9s p6dDYUjQm7S76Mk4Lu6fA== X-Spam-Score: -1.9 (-) X-Debbugs-Envelope-To: 10363 Cc: 653073@bugs.debian.org, rleigh@codelibre.net, debian-devel@lists.debian.org, 10363@debbugs.gnu.org, jidanni@jidanni.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.9 (-) "Alan Curry" writes: > jidanni@jidanni.org writes: >> >> Filesystem 1K-blocks Used Available Use% Mounted on >> rootfs 1071468 287940 729100 29% / >> /dev/disk/by-uuid/551e44e1-2cad-42cf-a716-f2e6caf9dc78 1071468 287940 729100 29% / > > (I'm replying only on the issue of the duplicate mount point. Someone else > can tackle the long ugly name.) > > The one with "rootfs" as its device is the initramfs which you automatically > get with all recent kernels. Even if you aren't using an initramfs, there's > an empty one built into the kernel which gets mounted as the first root > filesystem. The real root gets mounted on top of that. > > So this is a special case of a general problem with no easy solution: What > should df do when 2 filesystems are mounted at the same location? It can't > easily give correct information for both of them, since the later mount > obscures the earlier mount from view. The problem also exists in a larger extend with chroots. There will be lots of entries from outside the chroot that are inaccessible to a df running inside the chroot. What df should do is automatically skip the entries that are obscured or generally inaccessible. Unfortunately the kernel does not (re)sort the entries correctly following a mount --move call: rootfs / rootfs rw 0 0 none /sys sysfs rw,nosuid,nodev,noexec,relatime 0 0 none /proc proc rw,nosuid,nodev,noexec,relatime 0 0 none /dev devtmpfs rw,relatime,size=491516k,nr_inodes=122879,mode=755 0 0 none /dev/pts devpts rw,nosuid,noexec,relatime,gid=5,mode=620,ptmxmode=000 0 0 /dev/mapper/s-root / ext3 ro,relatime,errors=remount-ro,data=ordered 0 0 tmpfs /lib/init/rw tmpfs rw,nosuid,relatime,mode=755 0 0 ... Going by that list the /dev/mapper/s-root filesystems obscures the rootfs, /sys, /proc, /dev and /dev/pts. In reality though only the rootfs is obscured because the rest was moved prior to the initramfs switching / around. What the kernel should do is move the relevant entries so they appear below the filesystem they are moved to (and before any that do obscure them, moving them to the bottom isn't always the right solution). So at the moment is a bit of a guess which entries are real and which are obscured. The best you can do is check that each entry is actually a mountpoint and guess that the last of identical mountpoints is the right one. > If there's a way for df to get the correct information for the lower mount, I > don't know what it would be. If you have a process with a leftover cwd or > open fd in the obscured filesystem, you can use that. But generally you > won't. There afaik isn't and there should not be a way to do so. > But maybe we could do better than reporting incorrectly that the lower mount > has size and usage identical to the upper mount! At least df could print a > warning at the end if it has seen any duplicate entries. Perhaps there is > some way it could figure out which one is on top, and print a bunch of > question marks as the lower mount's statistics. Maybe compare the major/minor of the device node with statfs() output. > If df is running as root, it might be able to unshare(2) the mount namespace, > unmount the upper level, and then statfs the mount point again to get the > correct results for the lower level. That won't work in all cases (even in a > private namespace you can't unmount the filesystem containing your own cwd) > and it does nothing for you if you're not root, but still... it would be a > cool bonus in the cases where it does work. > > As a special case, "rootfs" should probably be excluded from the default > listing, since the initramfs is not very interesting most of the time. It > could still be shown with the -a option, although it would always have the > wrong statistics. Or if you really want to be impressive, default to showing > the initramfs if and only if it is the only thing mounted on "/" - so you can > run df within the initramfs before the real root is mounted and get the right > result. What if you only have a rootfs? Imho the /proc/mounts file should only contain entries visible in the processes mount namespace. So for normal systems the rootfs shouldn't appear and in chroots the list should be even shorter. > Or... (brace yourself for the most bold idea yet)... can you imagine a kernel > interface that would *cleanly* give access to obscured mount points? I fear that would let too much information escape from/into the mount namesapces. But there could be a /proc/global-mounts or something that is only readable from the root namespace. > Comments on any of the above? Do the BSDs have any bright ideas we can steal, > or is their df as embarrassingly bad at handling obscured mount points as > ours? MfG Goswin From debbugs-submit-bounces@debbugs.gnu.org Wed Jan 18 13:13:48 2012 Received: (at 10363) by debbugs.gnu.org; 18 Jan 2012 18:13:49 +0000 Received: from localhost ([127.0.0.1]:34630 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Rna16-00014Q-K6 for submit@debbugs.gnu.org; Wed, 18 Jan 2012 13:13:48 -0500 Received: from smtp.cs.ucla.edu ([131.179.128.62]:48965) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Rna14-00014E-D3 for 10363@debbugs.gnu.org; Wed, 18 Jan 2012 13:13:47 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp.cs.ucla.edu (Postfix) with ESMTP id 421EEA60003; Wed, 18 Jan 2012 10:12:38 -0800 (PST) X-Virus-Scanned: amavisd-new at smtp.cs.ucla.edu Received: from smtp.cs.ucla.edu ([127.0.0.1]) by localhost (smtp.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id BpN4+XcO9y8J; Wed, 18 Jan 2012 10:12:37 -0800 (PST) Received: from penguin.cs.ucla.edu (Penguin.CS.UCLA.EDU [131.179.64.200]) by smtp.cs.ucla.edu (Postfix) with ESMTPSA id D53AC39E800A; Wed, 18 Jan 2012 10:12:37 -0800 (PST) Message-ID: <4F170B94.3010304@cs.ucla.edu> Date: Wed, 18 Jan 2012 10:12:36 -0800 From: Paul Eggert Organization: UCLA Computer Science Department User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:8.0) Gecko/20111115 Thunderbird/8.0 MIME-Version: 1.0 To: Goswin von Brederlow Subject: Re: bug#10363: /etc/mtab -> /proc/mounts symlink affects df(1) output for References: <20111226232705.29921.qmail@kosh.dhis.org> <87k44p9jge.fsf@frosties.localnet> In-Reply-To: <87k44p9jge.fsf@frosties.localnet> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: -1.9 (-) X-Debbugs-Envelope-To: 10363 Cc: Alan Curry , 653073@bugs.debian.org, debian-devel@lists.debian.org, 10363@debbugs.gnu.org, jidanni@jidanni.org, rleigh@codelibre.net X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.9 (-) On 01/18/12 06:25, Goswin von Brederlow wrote: > What df should do is automatically skip the entries that are obscured or > generally inaccessible. Isn't this missing some of the larger context? df is just doing what lots of other programs do: finding out what file systems one has, and reporting statistics on them. It sounds suboptimal to require the maintainers of all these programs (coreutils, nautilus, etc.) to rewrite their apps to deal with obscured entries. Surely it would be better to have the kernel ordinarily return just the ordinary entries, and to return obscured entries only when they are specially requested. That way, this issue would be isolated to the few bits of code that really want to see obscured entries. From debbugs-submit-bounces@debbugs.gnu.org Thu Jan 19 05:29:02 2012 Received: (at 10363) by debbugs.gnu.org; 19 Jan 2012 10:29:02 +0000 Received: from localhost ([127.0.0.1]:35122 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1RnpEq-00037i-2A for submit@debbugs.gnu.org; Thu, 19 Jan 2012 05:29:01 -0500 Received: from fmmailgate02.web.de ([217.72.192.227]:36918) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1RnpEn-00037a-89 for 10363@debbugs.gnu.org; Thu, 19 Jan 2012 05:28:58 -0500 Received: from moweb001.kundenserver.de (moweb001.kundenserver.de [172.19.20.114]) by fmmailgate02.web.de (Postfix) with ESMTP id A2CCB1BFEA405 for <10363@debbugs.gnu.org>; Thu, 19 Jan 2012 11:27:45 +0100 (CET) Received: from frosties.localnet ([95.208.118.96]) by smtp.web.de (mrweb001) with ESMTPA (Nemesis) id 0LmcRH-1SM42W3LU3-00ZTQa; Thu, 19 Jan 2012 11:27:44 +0100 Received: from mrvn by frosties.localnet with local (Exim 4.77) (envelope-from ) id 1RnokE-0000c1-50; Thu, 19 Jan 2012 10:57:22 +0100 From: Goswin von Brederlow To: Paul Eggert Subject: Re: bug#10363: /etc/mtab -> /proc/mounts symlink affects df(1) output for References: <20111226232705.29921.qmail@kosh.dhis.org> <87k44p9jge.fsf@frosties.localnet> <4F170B94.3010304@cs.ucla.edu> Date: Thu, 19 Jan 2012 10:57:22 +0100 In-Reply-To: <4F170B94.3010304@cs.ucla.edu> (Paul Eggert's message of "Wed, 18 Jan 2012 10:12:36 -0800") Message-ID: <877h0o9fr1.fsf@frosties.localnet> User-Agent: Gnus/5.110009 (No Gnus v0.9) XEmacs/21.4.22 (linux, no MULE) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Provags-ID: V02:K0:i+oqigbV1lqhTKdT5KehebUeNKbjfFHrh+6qAMFvBVG NhWhRKhQC/+ZFUw056TMy64QtLBUjDbVnNlnw6hD86hgc2KGT2 ++QanEYAzhtQF+SbrgTNYPPCjeaLSfZtrPem4RrXnp2m2I+wJ7 /9aIQgnbqUm/Emqn4vuiOuZM9xScw4cG9m4cI1MC2ICupUTYge BDdnMWsjGyf8rkxQUVjng== X-Spam-Score: -1.9 (-) X-Debbugs-Envelope-To: 10363 Cc: Alan Curry , Goswin von Brederlow , 653073@bugs.debian.org, debian-devel@lists.debian.org, 10363@debbugs.gnu.org, jidanni@jidanni.org, rleigh@codelibre.net X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.9 (-) Paul Eggert writes: > On 01/18/12 06:25, Goswin von Brederlow wrote: >> What df should do is automatically skip the entries that are obscured or >> generally inaccessible. > > Isn't this missing some of the larger context? df is just doing what > lots of other programs do: finding out what file systems one has, > and reporting statistics on them. It sounds suboptimal to require > the maintainers of all these programs (coreutils, nautilus, etc.) > to rewrite their apps to deal with obscured entries. Surely it would > be better to have the kernel ordinarily return just the ordinary entries, > and to return obscured entries only when they are specially requested. > That way, this issue would be isolated to the few bits of code that really > want to see obscured entries. +1. Kernel knows best anyway. MfG Goswin From debbugs-submit-bounces@debbugs.gnu.org Thu Jan 19 10:50:05 2012 Received: (at 10363) by debbugs.gnu.org; 19 Jan 2012 15:50:05 +0000 Received: from localhost ([127.0.0.1]:35564 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1RnuFY-0004Gp-LE for submit@debbugs.gnu.org; Thu, 19 Jan 2012 10:50:05 -0500 Received: from smtp.cs.ucla.edu ([131.179.128.62]:57171) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1RnuFU-0004GD-Q8 for 10363@debbugs.gnu.org; Thu, 19 Jan 2012 10:50:02 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp.cs.ucla.edu (Postfix) with ESMTP id E1D54A60006; Thu, 19 Jan 2012 07:48:41 -0800 (PST) X-Virus-Scanned: amavisd-new at smtp.cs.ucla.edu Received: from smtp.cs.ucla.edu ([127.0.0.1]) by localhost (smtp.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w2DfYB2j991s; Thu, 19 Jan 2012 07:48:41 -0800 (PST) Received: from penguin.cs.ucla.edu (Penguin.CS.UCLA.EDU [131.179.64.200]) by smtp.cs.ucla.edu (Postfix) with ESMTPSA id 73A94A60005; Thu, 19 Jan 2012 07:48:41 -0800 (PST) Message-ID: <4F183B55.7040906@cs.ucla.edu> Date: Thu, 19 Jan 2012 07:48:37 -0800 From: Paul Eggert Organization: UCLA Computer Science Department User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:8.0) Gecko/20111115 Thunderbird/8.0 MIME-Version: 1.0 To: Henrique de Moraes Holschuh Subject: Re: [Pkg-sysvinit-devel] Bug#653073: bug#10363: /etc/mtab -> /proc/mounts symlink affects df(1) output for References: <20111226232705.29921.qmail@kosh.dhis.org> <87k44p9jge.fsf@frosties.localnet> <4F170B94.3010304@cs.ucla.edu> <877h0o9fr1.fsf@frosties.localnet> <20120119112300.GA20405@khazad-dum.debian.net> <20120119152924.GA9187@khazad-dum.debian.net> In-Reply-To: <20120119152924.GA9187@khazad-dum.debian.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: -1.9 (-) X-Debbugs-Envelope-To: 10363 Cc: Alan Curry , Goswin von Brederlow , 653073@bugs.debian.org, debian-devel@lists.debian.org, 10363@debbugs.gnu.org, jidanni@jidanni.org, rleigh@codelibre.net X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.9 (-) On 01/19/12 07:29, Henrique de Moraes Holschuh wrote: > Note: there is no reason why the kernel could not return the mount > information with shadowed paths removed in a separate procfs node, as > that would cause no security/troubleshooting problems. That's what I was thinking of, and it'd be a much better fix, as it would fix things for all applications. The current approach expects all app developers to modify their applications in order to deal with a feature that app developers typically don't know about and don't understand; this isn't a good way to introduce a new feature. From debbugs-submit-bounces@debbugs.gnu.org Thu Jan 19 11:38:38 2012 Received: (at 10363) by debbugs.gnu.org; 19 Jan 2012 16:38:38 +0000 Received: from localhost ([127.0.0.1]:35597 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Rnv0W-0005ek-2N for submit@debbugs.gnu.org; Thu, 19 Jan 2012 11:38:37 -0500 Received: from out3-smtp.messagingengine.com ([66.111.4.27]:34003) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Rnq6K-0004aL-0o for 10363@debbugs.gnu.org; Thu, 19 Jan 2012 06:24:20 -0500 Received: from compute3.internal (compute3.nyi.mail.srv.osa [10.202.2.43]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 43FDB2195E for <10363@debbugs.gnu.org>; Thu, 19 Jan 2012 06:23:04 -0500 (EST) Received: from frontend2.nyi.mail.srv.osa ([10.202.2.161]) by compute3.internal (MEProxy); Thu, 19 Jan 2012 06:23:04 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=date:from:to:cc:subject:message-id :references:mime-version:content-type:in-reply-to; s=smtpout; bh=jpaPFn5iG4fNlADIB/1Reh/BU70=; b=ize2VJxQSjNmZP+PF6WDlP0uDr3R B1CWuMUkrc6CvXZzI5bXWWSNNj+/hiwwRQX5Dw7FRhMjRci11uD+kkw3umI6m7Dc yIBE0nicqezcKBUsHBWZWsFCzxEt5QsPOv7JMjndxQk9vRcZS64vu/PBXslw/eHO PUiJtsxNp08/erg= X-Sasl-enc: 99VvEJ9aZIGSOcWCDuiTLX1azcpBUuBRG9xGrGPpkCqP 1326972183 Received: from khazad-dum.debian.net (unknown [201.82.73.183]) by mail.messagingengine.com (Postfix) with ESMTPSA id E95074824C7; Thu, 19 Jan 2012 06:23:03 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by localhost.khazad-dum.debian.net (Postfix) with ESMTP id CCB27E21ED; Thu, 19 Jan 2012 09:23:01 -0200 (BRST) X-Virus-Scanned: Debian amavisd-new at khazad-dum.debian.net Received: from khazad-dum.debian.net ([127.0.0.1]) by localhost (khazad-dum2.khazad-dum.debian.net [127.0.0.1]) (amavisd-new, port 10024) with LMTP id CuZrlpDp3o7Y; Thu, 19 Jan 2012 09:23:00 -0200 (BRST) Received: by khazad-dum.debian.net (Postfix, from userid 1000) id B65F3E2047; Thu, 19 Jan 2012 09:23:00 -0200 (BRST) Date: Thu, 19 Jan 2012 09:23:00 -0200 From: Henrique de Moraes Holschuh To: Goswin von Brederlow Subject: Re: bug#10363: /etc/mtab -> /proc/mounts symlink affects df(1) output for Message-ID: <20120119112300.GA20405@khazad-dum.debian.net> References: <20111226232705.29921.qmail@kosh.dhis.org> <87k44p9jge.fsf@frosties.localnet> <4F170B94.3010304@cs.ucla.edu> <877h0o9fr1.fsf@frosties.localnet> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <877h0o9fr1.fsf@frosties.localnet> X-GPG-Fingerprint: 1024D/1CDB0FE3 5422 5C61 F6B7 06FB 7E04 3738 EE25 DE3F 1CDB 0FE3 User-Agent: Mutt/1.5.20 (2009-06-14) X-Spam-Score: -2.6 (--) X-Debbugs-Envelope-To: 10363 X-Mailman-Approved-At: Thu, 19 Jan 2012 11:38:33 -0500 Cc: Paul Eggert , Alan Curry , 653073@bugs.debian.org, debian-devel@lists.debian.org, 10363@debbugs.gnu.org, jidanni@jidanni.org, rleigh@codelibre.net X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.6 (--) On Thu, 19 Jan 2012, Goswin von Brederlow wrote: > Paul Eggert writes: > > On 01/18/12 06:25, Goswin von Brederlow wrote: > >> What df should do is automatically skip the entries that are obscured or > >> generally inaccessible. > > > > Isn't this missing some of the larger context? df is just doing what > > lots of other programs do: finding out what file systems one has, > > and reporting statistics on them. It sounds suboptimal to require > > the maintainers of all these programs (coreutils, nautilus, etc.) > > to rewrite their apps to deal with obscured entries. Surely it would > > be better to have the kernel ordinarily return just the ordinary entries, > > and to return obscured entries only when they are specially requested. > > That way, this issue would be isolated to the few bits of code that really > > want to see obscured entries. > > +1. Kernel knows best anyway. The kernel has to return all entries that are visible to the current namespace, otherwise you pretty much cannot know about the existence of shadowed entries in the first place, and that has all sort of nasty implications for security and troubleshooting. The kernel should NOT include entries that are out of reach due to namespaces or chrooting, but I don't think this is quite correct right now. If you don't want to show to the user shadowed entries, fix it in the UI, maybe write a nice LGPL lib and get the various GNU utils to use it to avoid duplicated effort... or fix it in glibc, if applicable. But /proc/mounts really has to return complete information. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh From debbugs-submit-bounces@debbugs.gnu.org Thu Jan 19 11:38:39 2012 Received: (at 10363) by debbugs.gnu.org; 19 Jan 2012 16:38:39 +0000 Received: from localhost ([127.0.0.1]:35599 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Rnv0X-0005ep-Vy for submit@debbugs.gnu.org; Thu, 19 Jan 2012 11:38:38 -0500 Received: from out3-smtp.messagingengine.com ([66.111.4.27]:39093) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Rntwl-0003i2-PC for 10363@debbugs.gnu.org; Thu, 19 Jan 2012 10:30:41 -0500 Received: from compute2.internal (compute2.nyi.mail.srv.osa [10.202.2.42]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 77DBB20CB7 for <10363@debbugs.gnu.org>; Thu, 19 Jan 2012 10:29:27 -0500 (EST) Received: from frontend2.nyi.mail.srv.osa ([10.202.2.161]) by compute2.internal (MEProxy); Thu, 19 Jan 2012 10:29:27 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=date:from:to:cc:subject:message-id :references:mime-version:content-type:in-reply-to; s=smtpout; bh=gYD1b2f47CuvZrCET41+OBiRkco=; b=MJ7zAKfqWxWRBmgdLLpwIC/y3jJ6 uA0pfrs9IAO5loOp+bxgH3rhd9LXvTVEAKIqk3PnJDa4kMC5lH/d4I0PLf+656hc OGmWAeRTBOn7ujy8N4ozWCtb/dOSmTy8pa8340Rp4bJGbFOkhCcGx8gwbIMyoj7M TGwuTqconxORpdo= X-Sasl-enc: xyJGCpFk4+IBoDuXNfxMpLW8h9tLpwLkwJHaIbOWFSXb 1326986967 Received: from khazad-dum.debian.net (unknown [201.82.73.183]) by mail.messagingengine.com (Postfix) with ESMTPSA id 24B2F482521; Thu, 19 Jan 2012 10:29:27 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by localhost.khazad-dum.debian.net (Postfix) with ESMTP id 1A46BE0104; Thu, 19 Jan 2012 13:29:25 -0200 (BRST) X-Virus-Scanned: Debian amavisd-new at khazad-dum.debian.net Received: from khazad-dum.debian.net ([127.0.0.1]) by localhost (khazad-dum2.khazad-dum.debian.net [127.0.0.1]) (amavisd-new, port 10024) with LMTP id Y97U9-I9VVHM; Thu, 19 Jan 2012 13:29:24 -0200 (BRST) Received: by khazad-dum.debian.net (Postfix, from userid 1000) id 35C7AE1FFD; Thu, 19 Jan 2012 13:29:24 -0200 (BRST) Date: Thu, 19 Jan 2012 13:29:24 -0200 From: Henrique de Moraes Holschuh To: Goswin von Brederlow Subject: Re: [Pkg-sysvinit-devel] Bug#653073: bug#10363: /etc/mtab -> /proc/mounts symlink affects df(1) output for Message-ID: <20120119152924.GA9187@khazad-dum.debian.net> References: <20111226232705.29921.qmail@kosh.dhis.org> <87k44p9jge.fsf@frosties.localnet> <4F170B94.3010304@cs.ucla.edu> <877h0o9fr1.fsf@frosties.localnet> <20120119112300.GA20405@khazad-dum.debian.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20120119112300.GA20405@khazad-dum.debian.net> X-GPG-Fingerprint: 1024D/1CDB0FE3 5422 5C61 F6B7 06FB 7E04 3738 EE25 DE3F 1CDB 0FE3 User-Agent: Mutt/1.5.20 (2009-06-14) X-Spam-Score: -2.6 (--) X-Debbugs-Envelope-To: 10363 X-Mailman-Approved-At: Thu, 19 Jan 2012 11:38:33 -0500 Cc: Paul Eggert , Alan Curry , 653073@bugs.debian.org, debian-devel@lists.debian.org, 10363@debbugs.gnu.org, jidanni@jidanni.org, rleigh@codelibre.net X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.6 (--) On Thu, 19 Jan 2012, Henrique de Moraes Holschuh wrote: > On Thu, 19 Jan 2012, Goswin von Brederlow wrote: > > Paul Eggert writes: > > > On 01/18/12 06:25, Goswin von Brederlow wrote: > > >> What df should do is automatically skip the entries that are obscured or > > >> generally inaccessible. > > > > > > Isn't this missing some of the larger context? df is just doing what > > > lots of other programs do: finding out what file systems one has, > > > and reporting statistics on them. It sounds suboptimal to require > > > the maintainers of all these programs (coreutils, nautilus, etc.) > > > to rewrite their apps to deal with obscured entries. Surely it would > > > be better to have the kernel ordinarily return just the ordinary entries, > > > and to return obscured entries only when they are specially requested. > > > That way, this issue would be isolated to the few bits of code that really > > > want to see obscured entries. > > > > +1. Kernel knows best anyway. > > The kernel has to return all entries that are visible to the current > namespace, otherwise you pretty much cannot know about the existence of > shadowed entries in the first place, and that has all sort of nasty > implications for security and troubleshooting. > > The kernel should NOT include entries that are out of reach due to > namespaces or chrooting, but I don't think this is quite correct right now. > > If you don't want to show to the user shadowed entries, fix it in the > UI, maybe write a nice LGPL lib and get the various GNU utils to use it > to avoid duplicated effort... or fix it in glibc, if applicable. But > /proc/mounts really has to return complete information. Note: there is no reason why the kernel could not return the mount information with shadowed paths removed in a separate procfs node, as that would cause no security/troubleshooting problems. I do think kernel people will tell you to fix that in userspace, though. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh From debbugs-submit-bounces@debbugs.gnu.org Thu Jan 19 11:38:40 2012 Received: (at 10363) by debbugs.gnu.org; 19 Jan 2012 16:38:40 +0000 Received: from localhost ([127.0.0.1]:35601 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Rnv0Z-0005ew-Dv for submit@debbugs.gnu.org; Thu, 19 Jan 2012 11:38:40 -0500 Received: from out3-smtp.messagingengine.com ([66.111.4.27]:37298) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1RnutW-0005Rj-Qv for 10363@debbugs.gnu.org; Thu, 19 Jan 2012 11:31:24 -0500 Received: from compute5.internal (compute5.nyi.mail.srv.osa [10.202.2.45]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id A2F7121499 for <10363@debbugs.gnu.org>; Thu, 19 Jan 2012 11:30:09 -0500 (EST) Received: from frontend1.nyi.mail.srv.osa ([10.202.2.160]) by compute5.internal (MEProxy); Thu, 19 Jan 2012 11:30:09 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=date:from:to:cc:subject:message-id :references:mime-version:content-type:in-reply-to; s=smtpout; bh=1svKQvGVdVuzy1UnY7RtqFpJJsw=; b=k/5d3QuT+v4tKAQpGUtsFNSd8boy zTipRsnO42ARTvp9iYkrD2DD2V9gQliE7jfBpo1rXLwcsrbqNEISDPFxPH1ceH7G zzskzhTQZEoRq5+rLm1BBQX0OdkFcBupvBkAMjASSWQepKvU3zbaQd8T1flcH3WP OmATi+quxAs3BUw= X-Sasl-enc: bEPoUMUKSjuWbGDvGtuCaFMRhX10ZoYA5F+RxH2/2ARc 1326990609 Received: from khazad-dum.debian.net (unknown [201.82.73.183]) by mail.messagingengine.com (Postfix) with ESMTPSA id 4F8DC8E022A; Thu, 19 Jan 2012 11:30:09 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by localhost.khazad-dum.debian.net (Postfix) with ESMTP id A1BADE2233; Thu, 19 Jan 2012 14:30:07 -0200 (BRST) X-Virus-Scanned: Debian amavisd-new at khazad-dum.debian.net Received: from khazad-dum.debian.net ([127.0.0.1]) by localhost (khazad-dum2.khazad-dum.debian.net [127.0.0.1]) (amavisd-new, port 10024) with LMTP id C5CczJSmhau2; Thu, 19 Jan 2012 14:30:06 -0200 (BRST) Received: by khazad-dum.debian.net (Postfix, from userid 1000) id E1DD2E2203; Thu, 19 Jan 2012 14:30:06 -0200 (BRST) Date: Thu, 19 Jan 2012 14:30:06 -0200 From: Henrique de Moraes Holschuh To: Paul Eggert Subject: Re: [Pkg-sysvinit-devel] Bug#653073: bug#10363: /etc/mtab -> /proc/mounts symlink affects df(1) output for Message-ID: <20120119163006.GC9187@khazad-dum.debian.net> References: <20111226232705.29921.qmail@kosh.dhis.org> <87k44p9jge.fsf@frosties.localnet> <4F170B94.3010304@cs.ucla.edu> <877h0o9fr1.fsf@frosties.localnet> <20120119112300.GA20405@khazad-dum.debian.net> <20120119152924.GA9187@khazad-dum.debian.net> <4F183B55.7040906@cs.ucla.edu> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4F183B55.7040906@cs.ucla.edu> X-GPG-Fingerprint: 1024D/1CDB0FE3 5422 5C61 F6B7 06FB 7E04 3738 EE25 DE3F 1CDB 0FE3 User-Agent: Mutt/1.5.20 (2009-06-14) X-Spam-Score: -2.6 (--) X-Debbugs-Envelope-To: 10363 X-Mailman-Approved-At: Thu, 19 Jan 2012 11:38:33 -0500 Cc: Alan Curry , Goswin von Brederlow , 653073@bugs.debian.org, debian-devel@lists.debian.org, 10363@debbugs.gnu.org, jidanni@jidanni.org, rleigh@codelibre.net X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.6 (--) On Thu, 19 Jan 2012, Paul Eggert wrote: > On 01/19/12 07:29, Henrique de Moraes Holschuh wrote: > > Note: there is no reason why the kernel could not return the mount > > information with shadowed paths removed in a separate procfs node, as > > that would cause no security/troubleshooting problems. > > That's what I was thinking of, and it'd be a much better fix, > as it would fix things for all applications. > > The current approach expects all app developers to modify > their applications in order to deal with a feature that app > developers typically don't know about and don't understand; > this isn't a good way to introduce a new feature. On the app side, I will tell you what you're likely to get back from the crowd on LKML: write a proper BSD/MIT/LGPL library so that people don't have to reinvent the wheel, and fix it in userspace. It gets worse: such library interface already exists, in the form of getmntent, setmntent, addmntent, endmntent, hasmntopt, getmntent_r. So they will tell you to fix it in glibc. AFAIK, the kernel is not in any better position to remove shadowed paths than userspace, both are perfectly capable of doing it. Now, removing paths that are outside of the current process scope (due to namespaces or chroot or whatever), THAT is something only the kernel can do correctly... -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh From debbugs-submit-bounces@debbugs.gnu.org Thu Jan 19 17:18:31 2012 Received: (at 10363) by debbugs.gnu.org; 19 Jan 2012 22:18:31 +0000 Received: from localhost ([127.0.0.1]:35778 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Ro0JS-0006TN-Vb for submit@debbugs.gnu.org; Thu, 19 Jan 2012 17:18:31 -0500 Received: from smtp.cs.ucla.edu ([131.179.128.62]:34887) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Ro0JP-0006TD-Vd for 10363@debbugs.gnu.org; Thu, 19 Jan 2012 17:18:29 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by smtp.cs.ucla.edu (Postfix) with ESMTP id D5063A60006; Thu, 19 Jan 2012 14:17:12 -0800 (PST) X-Virus-Scanned: amavisd-new at smtp.cs.ucla.edu Received: from smtp.cs.ucla.edu ([127.0.0.1]) by localhost (smtp.cs.ucla.edu [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id FRm2qSmOgC+g; Thu, 19 Jan 2012 14:17:11 -0800 (PST) Received: from penguin.cs.ucla.edu (Penguin.CS.UCLA.EDU [131.179.64.200]) by smtp.cs.ucla.edu (Postfix) with ESMTPSA id C5342A60005; Thu, 19 Jan 2012 14:17:11 -0800 (PST) Message-ID: <4F189667.9030504@cs.ucla.edu> Date: Thu, 19 Jan 2012 14:17:11 -0800 From: Paul Eggert Organization: UCLA Computer Science Department User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:8.0) Gecko/20111115 Thunderbird/8.0 MIME-Version: 1.0 To: Henrique de Moraes Holschuh Subject: Re: bug#10363: [Pkg-sysvinit-devel] Bug#653073: bug#10363: /etc/mtab -> /proc/mounts symlink affects df(1) output for References: <20111226232705.29921.qmail@kosh.dhis.org> <87k44p9jge.fsf@frosties.localnet> <4F170B94.3010304@cs.ucla.edu> <877h0o9fr1.fsf@frosties.localnet> <20120119112300.GA20405@khazad-dum.debian.net> <20120119152924.GA9187@khazad-dum.debian.net> <4F183B55.7040906@cs.ucla.edu> <20120119163006.GC9187@khazad-dum.debian.net> In-Reply-To: <20120119163006.GC9187@khazad-dum.debian.net> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Spam-Score: -1.9 (-) X-Debbugs-Envelope-To: 10363 Cc: Alan Curry , Goswin von Brederlow , 653073@bugs.debian.org, debian-devel@lists.debian.org, 10363@debbugs.gnu.org, jidanni@jidanni.org, rleigh@codelibre.net X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.9 (-) On 01/19/12 08:30, Henrique de Moraes Holschuh wrote: > On the app side, I will tell you what you're likely to get back from the > crowd on LKML: write a proper BSD/MIT/LGPL library This argument would have stronger force if there were real code in a real application, code that solved the overall problem -- code that we could read and run. I don't know of any such code. > the kernel is not in any better position to remove shadowed paths > than userspace, both are perfectly capable of doing it. This seems to contradict an earlier comment made by someone else, "So at the moment is a bit of a guess which entries are real and which are obscured." I don't know who's right, nor do I understand what all the underlying issues are. I expect most other app developers are in a similar boat. It's not a good situation to be in. From debbugs-submit-bounces@debbugs.gnu.org Fri Jan 20 02:43:51 2012 Received: (at 10363) by debbugs.gnu.org; 20 Jan 2012 07:43:51 +0000 Received: from localhost ([127.0.0.1]:36021 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Ro98Y-0005Wy-PA for submit@debbugs.gnu.org; Fri, 20 Jan 2012 02:43:51 -0500 Received: from fmmailgate03.web.de ([217.72.192.234]:56774) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Ro98V-0005Wo-M9 for 10363@debbugs.gnu.org; Fri, 20 Jan 2012 02:43:49 -0500 Received: from moweb001.kundenserver.de (moweb001.kundenserver.de [172.19.20.114]) by fmmailgate03.web.de (Postfix) with ESMTP id 02D9C1B006C1A for <10363@debbugs.gnu.org>; Fri, 20 Jan 2012 08:42:31 +0100 (CET) Received: from frosties.localnet ([95.208.118.96]) by smtp.web.de (mrweb001) with ESMTPA (Nemesis) id 0MPGym-1RjjGu0gYi-00546w; Fri, 20 Jan 2012 08:42:29 +0100 Received: from mrvn by frosties.localnet with local (Exim 4.77) (envelope-from ) id 1Ro97C-0008Kd-Td; Fri, 20 Jan 2012 08:42:27 +0100 From: Goswin von Brederlow To: Henrique de Moraes Holschuh Subject: Re: bug#10363: /etc/mtab -> /proc/mounts symlink affects df(1) output for References: <20111226232705.29921.qmail@kosh.dhis.org> <87k44p9jge.fsf@frosties.localnet> <4F170B94.3010304@cs.ucla.edu> <877h0o9fr1.fsf@frosties.localnet> <20120119112300.GA20405@khazad-dum.debian.net> Date: Fri, 20 Jan 2012 08:42:26 +0100 In-Reply-To: <20120119112300.GA20405@khazad-dum.debian.net> (Henrique de Moraes Holschuh's message of "Thu, 19 Jan 2012 09:23:00 -0200") Message-ID: <874nvqn7kt.fsf@frosties.localnet> User-Agent: Gnus/5.110009 (No Gnus v0.9) XEmacs/21.4.22 (linux, no MULE) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Provags-ID: V02:K0:0a24EUDTmXjrSYS78PnOlv9rDfxLyG1gbMO48ne4mnO UkzKI2KCW0MVKO53M9Uv2aU6D9slU7IEVWKDuk2BECsp5Czc3n PLkrz9iXIzJf4qMDvp1TsjdoSmACgihVh4D5GGwO4yd8z5ZOTc 2wlnOTMKcKB3L0GY9j0gyFrjkvgHbai1CN+q6eomT2EivBRig7 Oh/zreFswKQkRSG/I+IOQ== X-Spam-Score: -1.9 (-) X-Debbugs-Envelope-To: 10363 Cc: Paul Eggert , Alan Curry , Goswin von Brederlow , 653073@bugs.debian.org, debian-devel@lists.debian.org, 10363@debbugs.gnu.org, jidanni@jidanni.org, rleigh@codelibre.net X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.9 (-) Henrique de Moraes Holschuh writes: > On Thu, 19 Jan 2012, Goswin von Brederlow wrote: >> Paul Eggert writes: >> > On 01/18/12 06:25, Goswin von Brederlow wrote: >> >> What df should do is automatically skip the entries that are obscured or >> >> generally inaccessible. >> > >> > Isn't this missing some of the larger context? df is just doing what >> > lots of other programs do: finding out what file systems one has, >> > and reporting statistics on them. It sounds suboptimal to require >> > the maintainers of all these programs (coreutils, nautilus, etc.) >> > to rewrite their apps to deal with obscured entries. Surely it would >> > be better to have the kernel ordinarily return just the ordinary entries, >> > and to return obscured entries only when they are specially requested. >> > That way, this issue would be isolated to the few bits of code that really >> > want to see obscured entries. >> >> +1. Kernel knows best anyway. > > The kernel has to return all entries that are visible to the current > namespace, otherwise you pretty much cannot know about the existence of > shadowed entries in the first place, and that has all sort of nasty > implications for security and troubleshooting. > > The kernel should NOT include entries that are out of reach due to > namespaces or chrooting, but I don't think this is quite correct right now. > > If you don't want to show to the user shadowed entries, fix it in the > UI, maybe write a nice LGPL lib and get the various GNU utils to use it > to avoid duplicated effort... or fix it in glibc, if applicable. But > /proc/mounts really has to return complete information. But isn't the rootfs out of reach because the initramfs "chroots" to the real root and starts /sbin/init? Back when pivot_root was used that was combined with an actual call to chroot. Before run-init combined the two. I'm not realy disagreeing with you but argue that the duplicate rootfs entry is not visible to the namespace. Same with later chroots: mrvn@frosties:~/chroot% sudo chroot . df df: `/sys': No such file or directory df: `/dev': No such file or directory df: `/dev/pts': No such file or directory df: `/run': No such file or directory df: `/tmp': No such file or directory df: `/usr': No such file or directory df: `/var': No such file or directory df: `/home': No such file or directory df: `/var/lib/nfs/rpc_pipefs': No such file or directory df: `/sys/fs/fuse/connections': No such file or directory Filesystem 1K-blocks Used Available Use% Mounted on rootfs 1789128 1808 1787320 1% / /dev/mapper/r-root 1789128 1808 1787320 1% / tmpfs 1789128 1808 1787320 1% / What it should show is only the last entry, the tmpfs the chroot is on. All other entries are not visible to the processes inside the chroot. Note that in a chroot any mountpoints inside the chroot have their prefix removed (/home/mrvn/chroot becomes /) while others are left as is. That is wrong too IMHO. The filesystem the chroots / is on should become / even if the chroot is a directory instead of a mountpoint and entries outside the chroot should not be listed at all. MfG Goswin From debbugs-submit-bounces@debbugs.gnu.org Fri Jan 20 02:52:17 2012 Received: (at 10363) by debbugs.gnu.org; 20 Jan 2012 07:52:17 +0000 Received: from localhost ([127.0.0.1]:36055 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Ro9Gi-0005mM-7G for submit@debbugs.gnu.org; Fri, 20 Jan 2012 02:52:17 -0500 Received: from fmmailgate03.web.de ([217.72.192.234]:39134) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1Ro9Gg-0005mF-7k for 10363@debbugs.gnu.org; Fri, 20 Jan 2012 02:52:15 -0500 Received: from moweb001.kundenserver.de (moweb001.kundenserver.de [172.19.20.114]) by fmmailgate03.web.de (Postfix) with ESMTP id C7F711B006F58 for <10363@debbugs.gnu.org>; Fri, 20 Jan 2012 08:50:57 +0100 (CET) Received: from frosties.localnet ([95.208.118.96]) by smtp.web.de (mrweb002) with ESMTPA (Nemesis) id 0Lxf5f-1ShdXv22jT-016UeA; Fri, 20 Jan 2012 08:50:57 +0100 Received: from mrvn by frosties.localnet with local (Exim 4.77) (envelope-from ) id 1Ro9FP-0000Dc-Bb; Fri, 20 Jan 2012 08:50:55 +0100 From: Goswin von Brederlow To: Henrique de Moraes Holschuh Subject: Re: [Pkg-sysvinit-devel] Bug#653073: bug#10363: /etc/mtab -> /proc/mounts symlink affects df(1) output for References: <20111226232705.29921.qmail@kosh.dhis.org> <87k44p9jge.fsf@frosties.localnet> <4F170B94.3010304@cs.ucla.edu> <877h0o9fr1.fsf@frosties.localnet> <20120119112300.GA20405@khazad-dum.debian.net> <20120119152924.GA9187@khazad-dum.debian.net> <4F183B55.7040906@cs.ucla.edu> <20120119163006.GC9187@khazad-dum.debian.net> Date: Fri, 20 Jan 2012 08:50:55 +0100 In-Reply-To: <20120119163006.GC9187@khazad-dum.debian.net> (Henrique de Moraes Holschuh's message of "Thu, 19 Jan 2012 14:30:06 -0200") Message-ID: <87zkdilsm8.fsf@frosties.localnet> User-Agent: Gnus/5.110009 (No Gnus v0.9) XEmacs/21.4.22 (linux, no MULE) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Provags-ID: V02:K0:4lDq9fay7WRuYK0wtFJ1RrfO1pzwgGdj9QKjHO3MCWC KrgPQM0utkdjqgCOLgYXiGg/kv3ExbUuZavO8fudtHbi5bkpVw khb+C88EC2JQnQ2fArwrUg+zsygxA1aBjoXbrLLEYZj113L21T RnBoFq9BlsQ2PtF6FTlEDLNO0VVWiqqYCBiPn915kcooHRoP14 x0w7Ctyfr+n34YbPfs1+w== X-Spam-Score: -1.9 (-) X-Debbugs-Envelope-To: 10363 Cc: Paul Eggert , Alan Curry , Goswin von Brederlow , 653073@bugs.debian.org, debian-devel@lists.debian.org, 10363@debbugs.gnu.org, jidanni@jidanni.org, rleigh@codelibre.net X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.9 (-) Henrique de Moraes Holschuh writes: > On Thu, 19 Jan 2012, Paul Eggert wrote: >> On 01/19/12 07:29, Henrique de Moraes Holschuh wrote: >> > Note: there is no reason why the kernel could not return the mount >> > information with shadowed paths removed in a separate procfs node, as >> > that would cause no security/troubleshooting problems. >> >> That's what I was thinking of, and it'd be a much better fix, >> as it would fix things for all applications. >> >> The current approach expects all app developers to modify >> their applications in order to deal with a feature that app >> developers typically don't know about and don't understand; >> this isn't a good way to introduce a new feature. > > On the app side, I will tell you what you're likely to get back from the > crowd on LKML: write a proper BSD/MIT/LGPL library so that people don't > have to reinvent the wheel, and fix it in userspace. It gets worse: such > library interface already exists, in the form of getmntent, setmntent, > addmntent, endmntent, hasmntopt, getmntent_r. So they will tell you to fix > it in glibc. How do you decide which of two conflicting entries is real? Since mount --move does not change the order of entries you can not just pick the last one. For example which entry is the right one with an output like this: tmpfs /run tmpfs rw,nosuid,noexec,relatime,size=357828k,mode=755 0 0 tmpfs /run tmpfs rw,suid,exec,relatime,size=357828k,mode=755 0 0 I don't think this can be fixed in userspace alone. At a minimum the kernel has to keep entries in order of visibility, i.e. the later entries always shadow earlier entries. Which means that on mount --move the kernel has to move the entry in /proc/mounts up or down as needed. MfG Goswin PS: I think you can also mount something below an already shadowed entry (if you have a shell with cwd in the shadowed one) and it would show up in the wrong spot in /proc/mounts. From debbugs-submit-bounces@debbugs.gnu.org Fri Jan 20 06:11:56 2012 Received: (at 10363) by debbugs.gnu.org; 20 Jan 2012 11:11:56 +0000 Received: from localhost ([127.0.0.1]:36400 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1RoCNw-0002vU-5n for submit@debbugs.gnu.org; Fri, 20 Jan 2012 06:11:56 -0500 Received: from mail-out.m-online.net ([212.18.0.9]:46613) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1RoCNu-0002vK-6K for 10363@debbugs.gnu.org; Fri, 20 Jan 2012 06:11:55 -0500 Received: from frontend1.mail.m-online.net (unknown [192.168.8.180]) by mail-out.m-online.net (Postfix) with ESMTP id 68A281C1DA0D; Fri, 20 Jan 2012 12:10:24 +0100 (CET) X-Auth-Info: v3ylCvSLx9+/iu0TRL47A+WuiOgYHahU4NcI/C4B1vc= Received: from igel.home (ppp-93-104-154-113.dynamic.mnet-online.de [93.104.154.113]) by mail.mnet-online.de (Postfix) with ESMTPA id A3D3C1C00093; Fri, 20 Jan 2012 12:10:24 +0100 (CET) Received: by igel.home (Postfix, from userid 501) id 25892CA299; Fri, 20 Jan 2012 12:10:23 +0100 (CET) From: Andreas Schwab To: Goswin von Brederlow Subject: Re: bug#10363: /etc/mtab -> /proc/mounts symlink affects df(1) output for References: <20111226232705.29921.qmail@kosh.dhis.org> <87k44p9jge.fsf@frosties.localnet> <4F170B94.3010304@cs.ucla.edu> <877h0o9fr1.fsf@frosties.localnet> <20120119112300.GA20405@khazad-dum.debian.net> <874nvqn7kt.fsf__3300.15804288468$1327045383$gmane$org@frosties.localnet> X-Yow: Somewhere in DOWNTOWN BURBANK a prostitute is OVERCOOKING a LAMB CHOP!! Date: Fri, 20 Jan 2012 12:10:23 +0100 In-Reply-To: <874nvqn7kt.fsf__3300.15804288468$1327045383$gmane$org@frosties.localnet> (Goswin von Brederlow's message of "Fri, 20 Jan 2012 08:42:26 +0100") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.92 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -1.9 (-) X-Debbugs-Envelope-To: 10363 Cc: Paul Eggert , Alan Curry , 653073@bugs.debian.org, debian-devel@lists.debian.org, 10363@debbugs.gnu.org, jidanni@jidanni.org, Henrique de Moraes Holschuh , rleigh@codelibre.net X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -1.9 (-) Goswin von Brederlow writes: > Note that in a chroot any mountpoints inside the chroot have their > prefix removed (/home/mrvn/chroot becomes /) while others are left as > is. That is wrong too IMHO. The filesystem the chroots / is on should > become / even if the chroot is a directory instead of a mountpoint and > entries outside the chroot should not be listed at all. You can get such a view from /proc/self/mountinfo. Andreas. -- Andreas Schwab, schwab@linux-m68k.org GPG Key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different." From debbugs-submit-bounces@debbugs.gnu.org Fri Jan 20 12:29:45 2012 Received: (at 10363) by debbugs.gnu.org; 20 Jan 2012 17:29:45 +0000 Received: from localhost ([127.0.0.1]:36886 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1RoIHY-0005eb-P1 for submit@debbugs.gnu.org; Fri, 20 Jan 2012 12:29:45 -0500 Received: from out3-smtp.messagingengine.com ([66.111.4.27]:53909) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1RoIHV-0005eT-Tz for 10363@debbugs.gnu.org; Fri, 20 Jan 2012 12:29:43 -0500 Received: from compute2.internal (compute2.nyi.mail.srv.osa [10.202.2.42]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id 07C3B210B8 for <10363@debbugs.gnu.org>; Fri, 20 Jan 2012 12:28:23 -0500 (EST) Received: from frontend2.nyi.mail.srv.osa ([10.202.2.161]) by compute2.internal (MEProxy); Fri, 20 Jan 2012 12:28:23 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=date:from:to:cc:subject:message-id :references:mime-version:content-type:in-reply-to; s=smtpout; bh=IB9yI1clLrLgwcyXOO8dMUgksME=; b=eDqKdva2GSGQgnfJVA3Ggm1t0eFT EuEa3iJzJ/FynxqcThKKcUSUU3rlgLEQXuS8MGULPG1LOTQYsgNrpEWN5erCtdEX ioplvxZOfpsGfnObITIARJ14HeEIKSiiWmyO0MgHrqdezgRtFg2nESqWVigiYU4y YS1mM/gc8RnmAm4= X-Sasl-enc: eyBsbzr0ozEnaX7LxYBoCxEtrBJrjwuM1igYByV3Tb58 1327080502 Received: from khazad-dum.debian.net (unknown [201.82.73.183]) by mail.messagingengine.com (Postfix) with ESMTPSA id 7DFEA482757; Fri, 20 Jan 2012 12:28:22 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by localhost.khazad-dum.debian.net (Postfix) with ESMTP id 786BEE0104; Fri, 20 Jan 2012 15:28:20 -0200 (BRST) X-Virus-Scanned: Debian amavisd-new at khazad-dum.debian.net Received: from khazad-dum.debian.net ([127.0.0.1]) by localhost (khazad-dum2.khazad-dum.debian.net [127.0.0.1]) (amavisd-new, port 10024) with LMTP id XLjHrz5JwoU7; Fri, 20 Jan 2012 15:28:19 -0200 (BRST) Received: by khazad-dum.debian.net (Postfix, from userid 1000) id 859B8E0160; Fri, 20 Jan 2012 15:28:19 -0200 (BRST) Date: Fri, 20 Jan 2012 15:28:19 -0200 From: Henrique de Moraes Holschuh To: Goswin von Brederlow Subject: Re: [Pkg-sysvinit-devel] Bug#653073: bug#10363: /etc/mtab -> /proc/mounts symlink affects df(1) output for Message-ID: <20120120172818.GA18413@khazad-dum.debian.net> References: <20111226232705.29921.qmail@kosh.dhis.org> <87k44p9jge.fsf@frosties.localnet> <4F170B94.3010304@cs.ucla.edu> <877h0o9fr1.fsf@frosties.localnet> <20120119112300.GA20405@khazad-dum.debian.net> <20120119152924.GA9187@khazad-dum.debian.net> <4F183B55.7040906@cs.ucla.edu> <20120119163006.GC9187@khazad-dum.debian.net> <87zkdilsm8.fsf@frosties.localnet> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87zkdilsm8.fsf@frosties.localnet> X-GPG-Fingerprint: 1024D/1CDB0FE3 5422 5C61 F6B7 06FB 7E04 3738 EE25 DE3F 1CDB 0FE3 User-Agent: Mutt/1.5.20 (2009-06-14) X-Spam-Score: -2.6 (--) X-Debbugs-Envelope-To: 10363 Cc: Paul Eggert , Alan Curry , 653073@bugs.debian.org, debian-devel@lists.debian.org, 10363@debbugs.gnu.org, jidanni@jidanni.org, rleigh@codelibre.net X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.6 (--) On Fri, 20 Jan 2012, Goswin von Brederlow wrote: > Henrique de Moraes Holschuh writes: > > On Thu, 19 Jan 2012, Paul Eggert wrote: > >> On 01/19/12 07:29, Henrique de Moraes Holschuh wrote: > >> > Note: there is no reason why the kernel could not return the mount > >> > information with shadowed paths removed in a separate procfs node, as > >> > that would cause no security/troubleshooting problems. > >> > >> That's what I was thinking of, and it'd be a much better fix, > >> as it would fix things for all applications. > >> > >> The current approach expects all app developers to modify > >> their applications in order to deal with a feature that app > >> developers typically don't know about and don't understand; > >> this isn't a good way to introduce a new feature. > > > > On the app side, I will tell you what you're likely to get back from the > > crowd on LKML: write a proper BSD/MIT/LGPL library so that people don't > > have to reinvent the wheel, and fix it in userspace. It gets worse: such > > library interface already exists, in the form of getmntent, setmntent, > > addmntent, endmntent, hasmntopt, getmntent_r. So they will tell you to fix > > it in glibc. > > How do you decide which of two conflicting entries is real? Since mount > --move does not change the order of entries you can not just pick the > last one. > > For example which entry is the right one with an output like this: > > tmpfs /run tmpfs rw,nosuid,noexec,relatime,size=357828k,mode=755 0 0 > tmpfs /run tmpfs rw,suid,exec,relatime,size=357828k,mode=755 0 0 > > I don't think this can be fixed in userspace alone. At a minimum the > kernel has to keep entries in order of visibility, i.e. the later > entries always shadow earlier entries. Which means that on mount --move > the kernel has to move the entry in /proc/mounts up or down as needed. Yes, it would have to order in that way. > PS: I think you can also mount something below an already shadowed entry > (if you have a shell with cwd in the shadowed one) and it would show up > in the wrong spot in /proc/mounts. I believe that's correct, and should be fixed. -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh From debbugs-submit-bounces@debbugs.gnu.org Fri Jan 20 12:42:58 2012 Received: (at 10363) by debbugs.gnu.org; 20 Jan 2012 17:42:58 +0000 Received: from localhost ([127.0.0.1]:36890 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1RoIUL-00063W-5E for submit@debbugs.gnu.org; Fri, 20 Jan 2012 12:42:57 -0500 Received: from out3-smtp.messagingengine.com ([66.111.4.27]:52631) by debbugs.gnu.org with esmtp (Exim 4.72) (envelope-from ) id 1RoIUE-00063I-St for 10363@debbugs.gnu.org; Fri, 20 Jan 2012 12:42:55 -0500 Received: from compute3.internal (compute3.nyi.mail.srv.osa [10.202.2.43]) by gateway1.nyi.mail.srv.osa (Postfix) with ESMTP id DA97E20A68 for <10363@debbugs.gnu.org>; Fri, 20 Jan 2012 12:41:31 -0500 (EST) Received: from frontend1.nyi.mail.srv.osa ([10.202.2.160]) by compute3.internal (MEProxy); Fri, 20 Jan 2012 12:41:31 -0500 DKIM-Signature: v=1; a=rsa-sha1; c=relaxed/relaxed; d= messagingengine.com; h=date:from:to:cc:subject:message-id :references:mime-version:content-type:in-reply-to; s=smtpout; bh=iqNwnEHBxJ19PvBKb+PEslqhoCM=; b=Y+fV7OxBGYj0FNmi1SpwSqUA84pk Buwvvg6UoHfSBbprodCXdBboNXyStIYAs0DXVkAo7E+qAePDd/Dlukdh17GRejax srZYewh7v0nM7mfb5rvyJXxPN7dlkfTHpx3lMPO4jxFhtK7WwpPzhJiH420KuS/E mV9GRTTaAz5OvUQ= X-Sasl-enc: GZ/J91LklqnmfRIxNe8JnwcOhF8H8R+YEPIJnYD61RiK 1327081291 Received: from khazad-dum.debian.net (unknown [201.82.73.183]) by mail.messagingengine.com (Postfix) with ESMTPSA id 858A88E0087; Fri, 20 Jan 2012 12:41:31 -0500 (EST) Received: from localhost (localhost [127.0.0.1]) by localhost.khazad-dum.debian.net (Postfix) with ESMTP id CBC81E1AC5; Fri, 20 Jan 2012 15:41:29 -0200 (BRST) X-Virus-Scanned: Debian amavisd-new at khazad-dum.debian.net Received: from khazad-dum.debian.net ([127.0.0.1]) by localhost (khazad-dum2.khazad-dum.debian.net [127.0.0.1]) (amavisd-new, port 10024) with LMTP id 3LqqfihJLthH; Fri, 20 Jan 2012 15:41:28 -0200 (BRST) Received: by khazad-dum.debian.net (Postfix, from userid 1000) id D76F7E2047; Fri, 20 Jan 2012 15:41:28 -0200 (BRST) Date: Fri, 20 Jan 2012 15:41:28 -0200 From: Henrique de Moraes Holschuh To: Goswin von Brederlow Subject: Re: bug#10363: /etc/mtab -> /proc/mounts symlink affects df(1) output for Message-ID: <20120120174128.GB18413@khazad-dum.debian.net> References: <20111226232705.29921.qmail@kosh.dhis.org> <87k44p9jge.fsf@frosties.localnet> <4F170B94.3010304@cs.ucla.edu> <877h0o9fr1.fsf@frosties.localnet> <20120119112300.GA20405@khazad-dum.debian.net> <874nvqn7kt.fsf@frosties.localnet> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <874nvqn7kt.fsf@frosties.localnet> X-GPG-Fingerprint: 1024D/1CDB0FE3 5422 5C61 F6B7 06FB 7E04 3738 EE25 DE3F 1CDB 0FE3 User-Agent: Mutt/1.5.20 (2009-06-14) X-Spam-Score: -2.6 (--) X-Debbugs-Envelope-To: 10363 Cc: Paul Eggert , Alan Curry , 653073@bugs.debian.org, debian-devel@lists.debian.org, 10363@debbugs.gnu.org, jidanni@jidanni.org, rleigh@codelibre.net X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Sender: debbugs-submit-bounces@debbugs.gnu.org Errors-To: debbugs-submit-bounces@debbugs.gnu.org X-Spam-Score: -2.6 (--) On Fri, 20 Jan 2012, Goswin von Brederlow wrote: > Henrique de Moraes Holschuh writes: > > The kernel has to return all entries that are visible to the current > > namespace, otherwise you pretty much cannot know about the existence of > > shadowed entries in the first place, and that has all sort of nasty > > implications for security and troubleshooting. > > > > The kernel should NOT include entries that are out of reach due to > > namespaces or chrooting, but I don't think this is quite correct right now. ... > But isn't the rootfs out of reach because the initramfs "chroots" to the > real root and starts /sbin/init? Back when pivot_root was used that > was combined with an actual call to chroot. Before run-init combined the > two. That's what I meant with "I don't think this is quite correct right now". > I'm not realy disagreeing with you but argue that the duplicate rootfs > entry is not visible to the namespace. I am not sure how /proc/mounts and friends should play with chroot(). I suppose it depends on whether one can actually reach that path somehow. If it is forever unacessible, IMO it is effectively outside the namespace and I believe it should not be visible. But that's where I reach the limits of my knowledge, and I can't really argue about it. > What it should show is only the last entry, the tmpfs the chroot is > on. All other entries are not visible to the processes inside the > chroot. I think you're correct in this. > Note that in a chroot any mountpoints inside the chroot have their > prefix removed (/home/mrvn/chroot becomes /) while others are left as > is. That is wrong too IMHO. The filesystem the chroots / is on should > become / even if the chroot is a directory instead of a mountpoint and > entries outside the chroot should not be listed at all. I also think you're correct here, but as I said, chroot() is tricky, and I am wary of arguing too much about it without strong knowledge about the nuances, which I don't have. Maybe this thread really ought to move to linux-fsdevel or LKML? -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique Holschuh From debbugs-submit-bounces@debbugs.gnu.org Mon Oct 15 11:15:50 2018 Received: (at 10363) by debbugs.gnu.org; 15 Oct 2018 15:15:50 +0000 Received: from localhost ([127.0.0.1]:50952 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gC4b0-00073w-4I for submit@debbugs.gnu.org; Mon, 15 Oct 2018 11:15:50 -0400 Received: from mail-pl1-f182.google.com ([209.85.214.182]:37366) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1gC4ax-0006xV-Mr; Mon, 15 Oct 2018 11:15:47 -0400 Received: by mail-pl1-f182.google.com with SMTP id u6-v6so6721344plz.4; Mon, 15 Oct 2018 08:15:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:cc:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=xOICWGB0VCpGdLr8uJLzvaYX3tLlOLEklrEbYQRGMWA=; b=QuMBROWa6ZTn/aa5HaAttVTaU8Fyjy5zSqfIElkYDzkuYAhVRGsMXt0WfOXM0WAo/Q Y9cUe5IhipWeuV8cZ2IvHjTRtHZVqfuKVT/9IvVJVKfbFdkHVxvH+CQCY+cRrHUYtDJH fTWIxvKWGwOOn9gY0MYIOdQhQyBFoAdUuFfUhlOBjDNaLqVl3mWMBjQsTTmADPmPrMba oeDX8K9lb84VI0N5CBSLPdT+tDUJz4UCIYW40QiYplmpURQhcGKiOB3UfVEC1cRbjvBe 1F+io4fiMqHoyXys/ee+9SclNOpuOF5qLD+By6RpY0bIShJgMpScZVj3o5wEO815xOyx KWdg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:cc:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=xOICWGB0VCpGdLr8uJLzvaYX3tLlOLEklrEbYQRGMWA=; b=IBT/1/kH+AodZOa6mh8TOdfQFO437cgCqH60zNBFsxfqKMD1BDBtq74CycHq3exzE6 7DFGhUmVsFIOEeIUSrvto7aHzrDUkK5VaY5nFymvn1+LMY2QVgSSuYXnPre0BANIk0PD /5zKaBZRFiPtozj0tNj3ivvVQ483XwD6CrU9NpP6BLGbFyZ31zlvRKMlMPHV4btazBiS Nr0zbmD3ewblbsfp5x9BBDxEkjMLczB2MQfRkSJs9UGs52+rhlveDFiIECM6J1tBQaFd WjD3Qx7T0nLrOAPv3ZyRUocrcL0td405pGh2djuFTJKmiRKEkV3AOUjvbzYi17R5OQMY O/qQ== X-Gm-Message-State: ABuFfohzLGpoh0ToX++foDX7fb0kC6E8X1AnDwY6XUaxPMkgsvi8ytGs f17up8qvMAX5nfv7gd8WooJkhiHZR+c= X-Google-Smtp-Source: ACcGV61qu552u9P6BPNBgT3FZFBFwcXg1M54iBi6lR041DO0qC6mlhDlENYCijgaI5cQJ0jIKxtKrQ== X-Received: by 2002:a17:902:bd98:: with SMTP id q24-v6mr7628310pls.284.1539616541186; Mon, 15 Oct 2018 08:15:41 -0700 (PDT) Received: from tomato.housegordon.com (moose.housegordon.com. [184.68.105.38]) by smtp.googlemail.com with ESMTPSA id h63-v6sm12109281pge.48.2018.10.15.08.15.39 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 15 Oct 2018 08:15:39 -0700 (PDT) Subject: Re: bug#10363: /etc/mtab -> /proc/mounts symlink affects df(1) output for References: <20111226232705.29921.qmail@kosh.dhis.org> <87k44p9jge.fsf@frosties.localnet> <4F170B94.3010304@cs.ucla.edu> <877h0o9fr1.fsf@frosties.localnet> <20120119112300.GA20405@khazad-dum.debian.net> <874nvqn7kt.fsf@frosties.localnet> <20120120174128.GB18413@khazad-dum.debian.net> From: Assaf Gordon Message-ID: <0e108ffc-76d2-978a-d493-d7bc5aeb59b0@gmail.com> Date: Mon, 15 Oct 2018 09:15:38 -0600 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.9.1 MIME-Version: 1.0 In-Reply-To: <20120120174128.GB18413@khazad-dum.debian.net> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Score: 1.2 (+) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: tags 10363 fixed close 10363 stop (triaging old bugs) Fix for 'long ugly UUID names' commited in https://git.savannah.gnu.org/cgit/coreutils.git/commit/?id=1e18d8416f9ef43bf08982cabe54220587061a08 [...] Content analysis details: (1.2 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 1.2 MISSING_HEADERS Missing To: header 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (assafgordon[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at http://www.dnswl.org/, no trust [209.85.214.182 listed in list.dnswl.org] X-Debbugs-Envelope-To: 10363 Cc: 10363@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.2 (/) tags 10363 fixed close 10363 stop (triaging old bugs) Fix for 'long ugly UUID names' commited in https://git.savannah.gnu.org/cgit/coreutils.git/commit/?id=1e18d8416f9ef43bf08982cabe54220587061a08 With no further follow-ups about other issues raised in this thread in 6 years, I'm closing this bug. regards, - assaf From unknown Sun Jun 22 22:44:34 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Tue, 13 Nov 2018 12:24:11 +0000 User-Agent: Fakemail v42.6.9 # This is a fake control message. # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator