* Re: [PATCH] umount: allow non-root umount of FUSE even if not in fstab
From: Petr Uzel @ 2011-03-29 8:46 UTC (permalink / raw)
To: Karel Zak; +Cc: util-linux, Miklos Szeredi
In-Reply-To: <20110328220344.GQ21093@nb.net.home>
[-- Attachment #1: Type: text/plain, Size: 1625 bytes --]
On Tue, Mar 29, 2011 at 12:03:44AM +0200, Karel Zak wrote:
> On Mon, Mar 28, 2011 at 04:04:56PM +0200, Petr Uzel wrote:
> > I have to admit that I don't like it very much, because:
>
> I don't like it too :-)
I'm not surprised :)
>
> > - it complicates umount
> > - duplicates code from fusermount
> > - should (???) be implemented using umount helpers
>
> [...]
>
> > + /* If this is fuse-based filesystem, allow user unmount even
> > + * if the FS is not in fstab.
> > + *
> > + * Based on fusermount code. */
> > + if (strcmp(mc->m.mnt_type, "fuse") == 0 ||
> > + strcmp(mc->m.mnt_type, "fuseblk") == 0 ||
> > + strncmp(mc->m.mnt_type, "fuse.", 5) == 0 ||
> > + strncmp(mc->m.mnt_type, "fuseblk.", 8) == 0) {
>
> Wouldn't be better to always call /sbin/umount.fuse for non-roots (except
> umount -i)?
Yes, that's what I meant by umount helpers. The problem is that AFAICS
fuse does not provide this helper.
@Miklos: what do you think? Would it make sense to have umount.fuse
(most likely as symlink to /sbin/mount.fuse)? I could look into it.
>
> I believe more and more that we need something like
>
> /etc/mount.d/{fuse,foo,...}.conf
>
> where we can define such behavior for some filesystems.
Hm, I fail to understand what (regarding to this 'issue') would
you configure there. I can imagine e.g. per-fs-type default mount
options or enable/disable 'user mounts' (-i) per fs-type.
Is this what you think that should be configured via /etc/mount.d/*,
or something else?
Thanks,
Petr
--
Petr Uzel
IRC: ptr_uzl @ freenode
[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: [PATCH] umount: allow non-root umount of FUSE even if not in fstab
From: Karel Zak @ 2011-03-29 8:28 UTC (permalink / raw)
To: Miklos Szeredi; +Cc: Petr Uzel, util-linux
In-Reply-To: <1301322200.22846.68.camel@tucsk.pomaz.szeredi.hu>
On Mon, Mar 28, 2011 at 04:23:20PM +0200, Miklos Szeredi wrote:
> On Mon, 2011-03-28 at 16:04 +0200, Petr Uzel wrote:
> > Hi all,
> >
> > I hacked the following patch with which it is possible to use
> > "umount $dir" instead of "fusermount -u $dir", which IMHO is an
> > improvement in usability. It seems to work (at least for me), however,
> > I have to admit that I don't like it very much, because:
> > - it complicates umount
> > - duplicates code from fusermount
>
> And this is not the only one that would have to be duplicated. The
> mount and umount races that were fixed in fusermount in recently and not
> so recently would also have to be added to util-linux, which would
> actually be a good thing, since in theory they could affect fstab based
> user mounts as well (though that is much more unlikely than with fuse,
> where the user chooses the mountpoint).
Maybe we need to call umount2() with UMOUNT_NOFOLLOW flag for
non-root users in umount(8). I think it should be enough for
umount(8) (where almost all is controlled by system admin in fstab).
See below. Comments?
Karel
>From 5cf67485d23dc4547eb5e54cbe96cc60837e36af Mon Sep 17 00:00:00 2001
From: Karel Zak <kzak@redhat.com>
Date: Tue, 29 Mar 2011 10:19:56 +0200
Subject: [PATCH] umount: use UMOUNT_NOFOLLOW for non-root users
Signed-off-by: Karel Zak <kzak@redhat.com>
---
mount/umount.c | 44 ++++++++++++++++++++++++++++++++++++--------
1 files changed, 36 insertions(+), 8 deletions(-)
diff --git a/mount/umount.c b/mount/umount.c
index 42671f4..0660b20 100644
--- a/mount/umount.c
+++ b/mount/umount.c
@@ -45,15 +45,22 @@ umount2(const char *path, int flags) {
}
#endif /* __NR_umount2 */
-#if !defined(MNT_FORCE)
-/* dare not try to include <linux/mount.h> -- lots of errors */
-#define MNT_FORCE 1
+#ifndef MNT_FORCE
+# define MNT_FORCE 0x00000001 /* Attempt to forcibily umount */
#endif
#endif /* MNT_FORCE */
-#if !defined(MNT_DETACH)
-#define MNT_DETACH 2
+#ifndef MNT_DETACH
+# define MNT_DETACH 0x00000002 /* Just detach from the tree */
+#endif
+
+#ifndef UMOUNT_NOFOLLOW
+# define UMOUNT_NOFOLLOW 0x00000008 /* Don't follow symlink on umount */
+#endif
+
+#ifndef UMOUNT_UNUSED
+#define UMOUNT_UNUSED 0x80000000 /* Flag guaranteed to be unused */
#endif
@@ -197,6 +204,21 @@ static void complain(int err, const char *dev) {
}
}
+/* Check whether the kernel supports UMOUNT_NOFOLLOW flag */
+static int umount_nofollow_support(void)
+{
+ int res = umount2("", UMOUNT_UNUSED);
+ if (res != -1 || errno != EINVAL)
+ return 0;
+
+ res = umount2("", UMOUNT_NOFOLLOW);
+ if (res != -1 || errno != ENOENT)
+ return 0;
+
+ return 1;
+}
+
+
/* Umount a single device. Return a status code, so don't exit
on a non-fatal error. We lock/unlock around each umount. */
static int
@@ -206,6 +228,7 @@ umount_one (const char *spec, const char *node, const char *type,
int isroot;
int res = 0;
int status;
+ int extra_flags = 0;
const char *loopdev;
int myloop = 0;
@@ -237,15 +260,18 @@ umount_one (const char *spec, const char *node, const char *type,
if (delloop && is_loop_device(spec))
myloop = 1;
+ if (restricted && umount_nofollow_support())
+ extra_flags |= UMOUNT_NOFOLLOW;
+
if (lazy) {
- res = umount2 (node, MNT_DETACH);
+ res = umount2 (node, MNT_DETACH | extra_flags);
if (res < 0)
umnt_err = errno;
goto writemtab;
}
if (force) { /* only supported for NFS */
- res = umount2 (node, MNT_FORCE);
+ res = umount2 (node, MNT_FORCE | extra_flags);
if (res == -1) {
int errsv = errno;
perror("umount2");
@@ -256,7 +282,9 @@ umount_one (const char *spec, const char *node, const char *type,
res = umount (node);
}
}
- } else
+ } else if (extra_flags)
+ res = umount2 (node, extra_flags);
+ else
res = umount (node);
if (res < 0)
--
1.7.3.4
^ permalink raw reply related
* Re: [PATCH] umount: allow non-root umount of FUSE even if not in fstab
From: Petr Uzel @ 2011-03-29 8:08 UTC (permalink / raw)
To: Miklos Szeredi; +Cc: util-linux
In-Reply-To: <1301322200.22846.68.camel@tucsk.pomaz.szeredi.hu>
[-- Attachment #1: Type: text/plain, Size: 1340 bytes --]
On Mon, Mar 28, 2011 at 04:23:20PM +0200, Miklos Szeredi wrote:
> On Mon, 2011-03-28 at 16:04 +0200, Petr Uzel wrote:
> > Hi all,
> >
> > I hacked the following patch with which it is possible to use
> > "umount $dir" instead of "fusermount -u $dir", which IMHO is an
> > improvement in usability. It seems to work (at least for me), however,
> > I have to admit that I don't like it very much, because:
> > - it complicates umount
> > - duplicates code from fusermount
>
> And this is not the only one that would have to be duplicated. The
> mount and umount races that were fixed in fusermount in recently and not
> so recently would also have to be added to util-linux, which would
> actually be a good thing, since in theory they could affect fstab based
> user mounts as well (though that is much more unlikely than with fuse,
> where the user chooses the mountpoint).
Do you mean this commit:
8b3a0c74a15e237eb4b7053774600f0ce3fff403
Fix race if two "fusermount -u" instances are run in parallel.
?
> > - should (???) be implemented using umount helpers
>
> The end goal is to implement permission checking for unprivileged mount
> and umount in the kernel.
OK, that sounds reasonable. Not something I'd have guts to look into,
though :)
Petr
--
Petr Uzel
IRC: ptr_uzl @ freenode
[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: [PATCH] umount: allow non-root umount of FUSE even if not in fstab
From: Karel Zak @ 2011-03-28 22:03 UTC (permalink / raw)
To: Petr Uzel; +Cc: util-linux, Miklos Szeredi
In-Reply-To: <20110328140454.GA4790@foxbat.suse.cz>
On Mon, Mar 28, 2011 at 04:04:56PM +0200, Petr Uzel wrote:
> I have to admit that I don't like it very much, because:
I don't like it too :-)
> - it complicates umount
> - duplicates code from fusermount
> - should (???) be implemented using umount helpers
[...]
> + /* If this is fuse-based filesystem, allow user unmount even
> + * if the FS is not in fstab.
> + *
> + * Based on fusermount code. */
> + if (strcmp(mc->m.mnt_type, "fuse") == 0 ||
> + strcmp(mc->m.mnt_type, "fuseblk") == 0 ||
> + strncmp(mc->m.mnt_type, "fuse.", 5) == 0 ||
> + strncmp(mc->m.mnt_type, "fuseblk.", 8) == 0) {
Wouldn't be better to always call /sbin/umount.fuse for non-roots (except
umount -i)?
I believe more and more that we need something like
/etc/mount.d/{fuse,foo,...}.conf
where we can define such behavior for some filesystems.
Karel
--
Karel Zak <kzak@redhat.com>
http://karelzak.blogspot.com
^ permalink raw reply
* Re: [PATCH] umount: allow non-root umount of FUSE even if not in fstab
From: Miklos Szeredi @ 2011-03-28 14:23 UTC (permalink / raw)
To: Petr Uzel; +Cc: util-linux
In-Reply-To: <20110328140454.GA4790@foxbat.suse.cz>
On Mon, 2011-03-28 at 16:04 +0200, Petr Uzel wrote:
> Hi all,
>
> I hacked the following patch with which it is possible to use
> "umount $dir" instead of "fusermount -u $dir", which IMHO is an
> improvement in usability. It seems to work (at least for me), however,
> I have to admit that I don't like it very much, because:
> - it complicates umount
> - duplicates code from fusermount
And this is not the only one that would have to be duplicated. The
mount and umount races that were fixed in fusermount in recently and not
so recently would also have to be added to util-linux, which would
actually be a good thing, since in theory they could affect fstab based
user mounts as well (though that is much more unlikely than with fuse,
where the user chooses the mountpoint).
> - should (???) be implemented using umount helpers
The end goal is to implement permission checking for unprivileged mount
and umount in the kernel.
Thanks,
Miklos
^ permalink raw reply
* [PATCH] umount: allow non-root umount of FUSE even if not in fstab
From: Petr Uzel @ 2011-03-28 14:04 UTC (permalink / raw)
To: util-linux; +Cc: Miklos Szeredi
[-- Attachment #1: Type: text/plain, Size: 2766 bytes --]
Hi all,
I hacked the following patch with which it is possible to use
"umount $dir" instead of "fusermount -u $dir", which IMHO is an
improvement in usability. It seems to work (at least for me), however,
I have to admit that I don't like it very much, because:
- it complicates umount
- duplicates code from fusermount
- should (???) be implemented using umount helpers
With regard to uhelpers: I spent some time looking into the fuse code,
but I don't think it could be done easily - has anybody investigated
this?
Related discussion (from 2006):
http://sourceforge.net/mailarchive/forum.php?thread_name=1253960851.6399.43.camel%40localhost.localdomain&forum_name=fuse-devel
This feature addresses:
https://fate.novell.com/310710
---------- 8< ---------- 8< -----------
This patch introduces an exception to the "no non-root unmounts
unless the mount is in fstab", which is necessary to allow
unmounting FUSE filesystems with umount (originally, one
had to use fusermount -u).
Umount makes the same checks as fusermount -u does, namely:
- if the fstype starts with fuse/fuseblk
- compares the user_id stored in /etc/mtab (or /proc/mounts) with
real UID of the calling user
Signed-off-by: Petr Uzel <petr.uzel@suse.cz>
---
mount/umount.c | 27 +++++++++++++++++++++++++++
1 files changed, 27 insertions(+), 0 deletions(-)
diff --git a/mount/umount.c b/mount/umount.c
index 42671f4..f887c6f 100644
--- a/mount/umount.c
+++ b/mount/umount.c
@@ -592,6 +592,33 @@ umount_file (char *arg) {
_("umount: it seems %s is mounted multiple times"),
file);
+ /* If this is fuse-based filesystem, allow user unmount even
+ * if the FS is not in fstab.
+ *
+ * Based on fusermount code. */
+ if (strcmp(mc->m.mnt_type, "fuse") == 0 ||
+ strcmp(mc->m.mnt_type, "fuseblk") == 0 ||
+ strncmp(mc->m.mnt_type, "fuse.", 5) == 0 ||
+ strncmp(mc->m.mnt_type, "fuseblk.", 8) == 0) {
+ char *fuse_uidstr;
+ fuse_uidstr = get_option_value(mc->m.mnt_opts, "user=");
+ if (!fuse_uidstr)
+ fuse_uidstr = get_option_value(mc->m.mnt_opts, "user_id=");
+ if (fuse_uidstr) {
+ char uidstr[32];
+ unsigned uidlen;
+ uidlen = sprintf(uidstr, "%u", getuid());
+ if (strncmp(uidstr, fuse_uidstr, uidlen) == 0) {
+ if (verbose)
+ printf(_("Unmounting %s (FUSE filesystem, mounted by uid=%s)\n"),
+ arg, uidstr);
+ int ret = umount_one(arg, arg, arg, arg, NULL);
+ free(fuse_uidstr);
+ return ret;
+ }
+ }
+ }
+
/* If fstab contains the two lines
/dev/sda1 /mnt/zip auto user,noauto 0 0
/dev/sda4 /mnt/zip auto user,noauto 0 0
--
1.7.3.4
Petr
--
Petr Uzel
IRC: ptr_uzl @ freenode
[-- Attachment #2: Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply related
* [PATCH] getopt: [getopt.c] add static qualifiers
From: Olivier Mengué @ 2011-03-27 16:29 UTC (permalink / raw)
To: util-linux; +Cc: Olivier Mengué
In-Reply-To: <1301243396-26240-1-git-send-email-dolmen@cpan.org>
Signed-off-by: Olivier Mengué <dolmen@cpan.org>
---
getopt/getopt.c | 52 ++++++++++++++++++++++++++--------------------------
1 files changed, 26 insertions(+), 26 deletions(-)
diff --git a/getopt/getopt.c b/getopt/getopt.c
index cea2f22..2e7109d 100644
--- a/getopt/getopt.c
+++ b/getopt/getopt.c
@@ -59,27 +59,27 @@ typedef enum {BASH,TCSH} shell_t;
/* Some global variables that tells us how to parse. */
-shell_t shell=BASH; /* The shell we generate output for. */
-int quiet_errors=0; /* 0 is not quiet. */
-int quiet_output=0; /* 0 is not quiet. */
-int quote=1; /* 1 is do quote. */
-int alternative=0; /* 0 is getopt_long, 1 is getopt_long_only */
+static shell_t shell=BASH; /* The shell we generate output for. */
+static int quiet_errors=0; /* 0 is not quiet. */
+static int quiet_output=0; /* 0 is not quiet. */
+static int quote=1; /* 1 is do quote. */
+static int alternative=0; /* 0 is getopt_long, 1 is getopt_long_only */
/* Function prototypes */
-void *our_malloc(size_t size);
-void *our_realloc(void *ptr, size_t size);
-const char *normalize(const char *arg);
-int generate_output(char * argv[],int argc,const char *optstr,
- const struct option *longopts);
+static void *our_malloc(size_t size);
+static void *our_realloc(void *ptr, size_t size);
+static const char *normalize(const char *arg);
+static int generate_output(char * argv[],int argc,const char *optstr,
+ const struct option *longopts);
int main(int argc, char *argv[]);
-void parse_error(const char *message);
-void add_long_options(char *options);
-void add_longopt(const char *name,int has_arg);
-void print_help(void);
-void set_shell(const char *new_shell);
-void set_initial_shell(void);
-
-void *our_malloc(size_t size)
+static void parse_error(const char *message);
+static void add_long_options(char *options);
+static void add_longopt(const char *name,int has_arg);
+static void print_help(void);
+static void set_shell(const char *new_shell);
+static void set_initial_shell(void);
+
+static void *our_malloc(size_t size)
{
void *ret=malloc(size);
if (! ret) {
@@ -89,7 +89,7 @@ void *our_malloc(size_t size)
return(ret);
}
-void *our_realloc(void *ptr, size_t size)
+static void *our_realloc(void *ptr, size_t size)
{
void *ret=realloc(ptr,size);
if (! ret && size) {
@@ -108,7 +108,7 @@ void *our_realloc(void *ptr, size_t size)
* This function returns a pointer to a buffer that is overwritten by
* each call.
*/
-const char *normalize(const char *arg)
+static const char *normalize(const char *arg)
{
static char *BUFFER=NULL;
const char *argptr=arg;
@@ -172,8 +172,8 @@ const char *normalize(const char *arg)
* optstr must contain the short options, and longopts the long options.
* Other settings are found in global variables.
*/
-int generate_output(char * argv[],int argc,const char *optstr,
- const struct option *longopts)
+static int generate_output(char * argv[],int argc,const char *optstr,
+ const struct option *longopts)
{
int exit_code = 0; /* We assume everything will be OK */
int opt;
@@ -222,7 +222,7 @@ int generate_output(char * argv[],int argc,const char *optstr,
* If message is NULL, we already sent a message, we just exit with a helpful
* hint.
*/
-void parse_error(const char *message)
+static void parse_error(const char *message)
{
if (message)
fprintf(stderr,"getopt: %s\n",message);
@@ -237,7 +237,7 @@ static int long_options_nr=0; /* Nr of used elements in array */
#define init_longopt() add_longopt(NULL,0)
/* Register a long option. The contents of name is copied. */
-void add_longopt(const char *name,int has_arg)
+static void add_longopt(const char *name,int has_arg)
{
char *tmp;
if (!name) { /* init */
@@ -276,7 +276,7 @@ void add_longopt(const char *name,int has_arg)
* separated by commas or whitespace.
* This nukes options!
*/
-void add_long_options(char *options)
+static void add_long_options(char *options)
{
int arg_opt;
char *tokptr=strtok(options,", \t\n");
@@ -301,7 +301,7 @@ void add_long_options(char *options)
}
}
-void set_shell(const char *new_shell)
+static void set_shell(const char *new_shell)
{
if (!strcmp(new_shell,"bash"))
shell=BASH;
@@ -315,7 +315,7 @@ void set_shell(const char *new_shell)
parse_error(_("unknown shell after -s or --shell argument"));
}
-void print_help(void)
+static void print_help(void)
{
fputs(_("Usage: getopt optstring parameters\n"),stderr);
fputs(_(" getopt [options] [--] optstring parameters\n"),stderr);
--
1.7.1
^ permalink raw reply related
* Re: mounting FreeBSD partition in Linux (Fedora 14)
From: J B @ 2011-03-22 8:14 UTC (permalink / raw)
To: util-linux-ng
In-Reply-To: <AANLkTimmV34u+t9zDJ44AiAncU1PeSv9Rsn+qkvgeKVS@mail.gmail.com>
On Thu, Mar 17, 2011 at 10:03 PM, J B <jb.1234abcd@gmail.com> wrote:
> Part 3.
> ...
Part 4.
Summary of the thread:
It is apparent that Linux, besides some minor bugs detected here, handles
*BSD file systems in an awkward way.
I say *BSD, as I assume that the FreeBSD test results probably appply to
OpenBSD and NetBSD as well due to similarity in their partition/slices
structure of their installations.
The issue is clear.
Linux kernel assigning device names to *BSD slices following those already
taken by Linux may cause serious problems when disk space is shared by both
OSs, e.g.
# fdisk -l /dev/sda
...
/dev/sda1 63 81920159 40960048+ 7 HPFS/NTFS
/dev/sda2 * 81920160 111222719 14651280 a5 FreeBSD
...
/dev/sda9 216715023 246017519 14651248+ 83 Linux
# dmesg | grep bsd
[ 1.550749] sda2: <bsd: sda10 sda11 sda12 sda13 sda14 >
------------------------------------------------------------------------------------------------------
From: Mikkel <mikkel <at> infinity-ltd.com>
It looks like the FreeBSD partition is being treated like an
extended partition, and the slices as logical partitions.
One thing to keep in mind is that the use of UUID or at least
partition labels are the preferred way to make sure the same
partition is mounted in the same place. It is too easy to change
drive letter designations by changing the boot drive in the BIOS, or
swapping cables to the drives. For that matter, by BIOS lets me set
the device order by drive, regardless of what SATA port the drive is
plugged into. When you get into USB connected storage, it gets even
more confusing when trying to use drive letter/partition to set the
mount point.
Mikkel
-------
On 03/18/2011 01:36 PM, JB wrote:
> ...
> These are the problems:
> 1. Linux has two widely used partition table display/manipulation entries:
> fdisk
> cfdisk
> and there are more of them.
> If none of them show all partitions (inclusive *BSD slices) as in
> an example above, then these entries are fooling users and sysadmins.
> This is lunacy and can be costly. Believe it or not but users rely on
> truthfullness and clarity (nothing shall be hidden) when it comes to
> the one and only one source of a particular info, based on which they make
> decisions.
This is a problem with the specific tools. They do not stop you when
you try and mix a DOS partition table and a BSD disklabel on the
same drive. The problem is that BSD is letting you mix the partition
tables on the same drive. You have to remember that fdisk and cfdisk
are old tools that were written in the days when an admin was
supposed to know what he was doing, and the tools will allow him to
shoot himself in the foot if that is what he wants. The newer tools
like parted make this harder, but you can still do it. You might
want to read the man pages on the limitations of fdisk and cfdisk.
> What if they decide they need an additional partition and look at fdisk
> for the next available (they do not see hidden *BSD slices) ?
> Is that not dangerous ?
Sure. That is a problem with using the old tools. You are not
supposed to mix DOS and BSD type partition table on the same drive,
but if that is what you want to do, they will let you. You will also
run into the same problem if you have Windows on the drive, and add
a logical drive. Linux handles this, as they use the same method
when dealing with a DOS partition table.
> 2. I have shown that *BSD slice /dev/≤name> can be temporarily mounted (and
> serve as a source of data) and at the same time the same /dev/≤name> can
> be used to create a new Linux partition.
> Is that not dangerous ?
Definitly - you should not try and mix a DOS partition table with a
BSD disk label partition table. They are not compatible. Do not try
to use tools that do exactly what you tell them to do, and let you
decide if that is the correct thing to do if you do not want to run
into the problem.
> 3. I have shown that *BSD slice /dev/≤name> can be permanently mounted thru
> /etc/fstab (and serve as a source of data) and at the same time the same
> /dev/≤name> can be used to create a new Linux partition.
> After that, due to mismatch of superblock/bad magic number that *BSD mount
> will be refused.
> Is that not dangerous ?
> If that /dev/≤name> were used to create a new stand-alone UFS partition
> (or anything for that matter that would match UFS superblock/bad magic
> number), perhaps the fstab-base auto mount would be successful, serving who
> knows what data.
> Is that not dangerous ?
>
Yes, it is. Linux should refuse to mount a drive with a mix of DOS
type and BSD type partitions on the same drive, or at least mount it
read/only. Then again, BSD should refuse to create partitions on a
drive that already has a DOS type partition table.
While you are checking things out, see how Linux handles a drive
with a proper BSD partition table (drivelabel). I suspect that fdisk
will report things properly, and it will get mounted correctly under
Linux.
My take on this is that fdisk on *BSD does not stop you from
shooting yourself in the foot by creating a partition table like
this, and fdisk under Linux does not stop you from shooting yourself
in the foot again. This is why you need root access to do these
things - you are supposed to know what you are doing, and not do
things like this. But if you have a reason for doing them, the
system will let you.
Did you know that you can use the entire drive, without a partition
table, as a file system? If you want to run "mke2fs /dev/sda" as
root, it will let you. If you want to run "tar -cf /dev/sdb /home"
as root, and you have a sdb, it will use the entire drive as a tar
archive. And it will do it even if you have a partition table, and
mounted file systems on it. (It will not do it if you have /dev/sdb
mounted, but it will if you have /dev/sdb1 mounted.)
I have not tried it, but I suspect you can do the same thing under
*BSD. It should work on ANY UNIX-type system as long as you are the
super-user, what ever they call him.
Mikkel
------------------------------------------------------------------------------------------------------
I forgot to mention one more problem:
4. The /dev/≤name> assigned to Linux partition/*BSD slices have a "floating"
nature as they are *appended* to Linux partitions.
As a result they will be changed back and forth according to the latest
changes affecting the tail of Linux partitions layout, effective with each
system reboot.
This also blows up the fstab-based auto mounts of *BSD slices/Linux
partitions.
Is that not dangerous ?
Yes, the power of super-user should be clear to any body who has the password.
The "let-them-shoot-themselves-in-the-foot" or "no hand-holding" philosophy
has justification where work of senses and professional skills should be in
the forefront.
But, there are others who think the system (sometimes very high-end, expensive,
and important) would be better off if dangerous actions were verified
(e.g. cross-checked) and at least warned of, if not prohibited, because
mistakes could be too costly to all involved.
I think making fdisk and cfdisk list these *BSD slices/Linux partitions would
be the minimum requirement; this would remove the accusation about them being
hidden from view.
Then, yes, let the users be responsible for their own actions.
JB
^ permalink raw reply
* Re: mounting FreeBSD partition in Linux (Fedora 14)
From: J B @ 2011-03-18 7:06 UTC (permalink / raw)
To: util-linux-ng
In-Reply-To: <AANLkTimmV34u+t9zDJ44AiAncU1PeSv9Rsn+qkvgeKVS@mail.gmail.com>
> ...
> While having that /dev/sda10 (FreeBSD slice) mounted as above, I used cfdisk
> and added /dev/sda10 Linux partition (right after /dev/sda9 of course).
>
> To my surprise, I discovered that after that df and mount do not show that
> FreeBSD /dev/sda10 mounted partition ! Magically disappeared :-)
> ...
Sorry, not exactly.
The cfdisk action did not cause it of course; it ends with a write command (it
is suggested to reboot to make the changes permanent).
But until that time it creates a presumably semi-permanent state of /dev/sda10
being in cfdisk and fdisk displays, and at the same time df and mount showing
/dev/sda10 mounted as UFS partition on /media mount point.
A subsequent reboot cleared that temporary manual /media mount.
> ...
> What would have happened (as I suggested it previously) if I put that FreeBSD
> /dev/sda10 in /etc/fstab ?
> That new Linux /dev/sda10 partition would be auto mounted at that mount point,
> which would presumably be a source of data for some system or user app ...
That test was done by me.
# cat /etc/fstab
...
/dev/sda10 /media ufs ro,ufstype=ufs2 0 0
...
In this case /dev/sda10 was already a Linux parition per above and the mount
failed as shown in boot log:
# dmesg
...
[ 18.597349] EXT4-fs (sda7): re-mounted. Opts: (null)
[ 18.835869] ufs_read_super: bad magic number
[ 20.743108] Adding 2933244k swap on /dev/sda5. Priority:-1 extents:1
across:2933244k
...
But other bad outcomes are possible (see next post).
> ...
JB
^ permalink raw reply
* Re: Adding --color option to script?
From: Philip Prindeville @ 2011-03-10 22:18 UTC (permalink / raw)
To: Karel Zak; +Cc: util-linux
In-Reply-To: <20101231000329.GB17311@nb.net.home>
On 12/30/10 4:03 PM, Karel Zak wrote:
> On Thu, Dec 23, 2010 at 02:25:02PM -0800, Philip Prindeville wrote:
>> I would love to see an option like --color which used terminal
>> colors to highlight STDERR output (or, in a pinch, maybe bold it on
>> terminals that don't support color... if they still exist).
> The script(1) command does not work on this level. It reads data
> directly from master side of the terminal. It means that we are not
> able to distinguish between stdout and stderr.
>
>> Sound reasonable?
> Yes, but I don't see a way how to implement it.
>
> Karel
>
I just realized... it can be done by having two ptys, one for stdin/stdout, and another just for stderr.
-Philip
^ permalink raw reply
* Re: [PATCH] try to 'remount,ro' once if the kernel ignores the ro request for bind mounts
From: Karel Zak @ 2011-02-21 9:19 UTC (permalink / raw)
To: Stefan Tauner; +Cc: util-linux
In-Reply-To: <201102200214.p1K2EZ2m006839@mail2.student.tuwien.ac.at>
On Sun, Feb 20, 2011 at 03:14:30AM +0100, Stefan Tauner wrote:
> i sent the patch below ~10 days ago and did not receive any feedback
> whatsoever. if it's wrong or deemed unneeded, i'd really like to hear
> your opinion why. thanks!
I'm still not sure if mount(8) is the right place to fix odd kernel
behaviour. Anyway, your patch seems like a usable workaround.
I'll try to apply the patch later (it will necessary to modify
libmount, because the library is not able to add a new entry to mtab
for MS_REMOUNT requests).
Karel
--
Karel Zak <kzak@redhat.com>
http://karelzak.blogspot.com
^ permalink raw reply
* Re: [PATCH] try to 'remount,ro' once if the kernel ignores the ro request for bind mounts
From: Stefan Tauner @ 2011-02-20 2:14 UTC (permalink / raw)
To: util-linux; +Cc: Stefan Tauner
In-Reply-To: <201102101802.p1AI2Dp0009456@mail2.student.tuwien.ac.at>
Hey there!
i sent the patch below ~10 days ago and did not receive any feedback
whatsoever. if it's wrong or deemed unneeded, i'd really like to hear
your opinion why. thanks!
On Thu, 10 Feb 2011 19:02:05 +0100
Stefan Tauner <stefan.tauner@student.tuwien.ac.at> wrote:
> Hello,
>
> the linux kernel ignores (some?) options when they are used in bind
> mounts. Because of this 'mount' issues a warning if bind mounting with
> the ro option results in a writable mount (since 2009).
> From my point of view this is an error in the kernel because it does
> not report that and should be fixed. Nevertheless since mount already
> checks for this failure it is not a big change to just retry with the
> MS_REMOUNT flag added, which normally should succeed. If not we can
> still warn as before. This would allow using "bind,ro" in /etc/fstab.
> The patch below implements that.
>
> (please cc me)
>
> Signed-off-by: Stefan Tauner <stefan.tauner@student.tuwien.ac.at>
> ---
> mount/mount.c | 14 +++++++++-----
> 1 files changed, 9 insertions(+), 5 deletions(-)
>
> diff --git a/mount/mount.c b/mount/mount.c
> index f5b3521..28a05f9 100644
> --- a/mount/mount.c
> +++ b/mount/mount.c
> @@ -1655,14 +1655,18 @@ try_mount_one (const char *spec0, const char
> *node0, const char *types0, }
>
> /* Kernel allows to use MS_RDONLY for bind mounts, but the
> read-only request
> - * could be silently ignored. Check it to avoid 'ro' in mtab and
> 'rw' in
> - * /proc/mounts.
> + * could be silently ignored. Check that and retry with MS_REMOUNT
> once. If it
> + * is still rw honor it to avoid 'ro' in mtab and 'rw'
> in /proc/mounts. */
> if (!fake && mnt5_res == 0 &&
> (flags & MS_BIND) && (flags & MS_RDONLY)
> && !is_readonly(node)) { -
> - printf(_("mount: warning: %s seems to be mounted
> read-write.\n"), node);
> - flags &= ~MS_RDONLY;
> + if (!(flags & MS_REMOUNT)) {
> + flags |= MS_REMOUNT;
> + goto mount_retry;
> + } else {
> + printf(_("mount: warning: %s seems to be mounted
> read-write.\n"), node);
> + flags &= ~MS_RDONLY;
> + }
> }
>
> /* Kernel can silently add MS_RDONLY flag when mounting file
> system that
--
Kind regards/Mit freundlichen Grüßen, Stefan Tauner
^ permalink raw reply
* [PATCH] try to 'remount,ro' once if the kernel ignores the ro request for bind mounts
From: Stefan Tauner @ 2011-02-10 18:02 UTC (permalink / raw)
To: util-linux; +Cc: Stefan Tauner
Hello,
the linux kernel ignores (some?) options when they are used in bind
mounts. Because of this 'mount' issues a warning if bind mounting with
the ro option results in a writable mount (since 2009).
>From my point of view this is an error in the kernel because it does
not report that and should be fixed. Nevertheless since mount already
checks for this failure it is not a big change to just retry with the
MS_REMOUNT flag added, which normally should succeed. If not we can
still warn as before. This would allow using "bind,ro" in /etc/fstab.
The patch below implements that.
(please cc me)
Signed-off-by: Stefan Tauner <stefan.tauner@student.tuwien.ac.at>
---
mount/mount.c | 14 +++++++++-----
1 files changed, 9 insertions(+), 5 deletions(-)
diff --git a/mount/mount.c b/mount/mount.c
index f5b3521..28a05f9 100644
--- a/mount/mount.c
+++ b/mount/mount.c
@@ -1655,14 +1655,18 @@ try_mount_one (const char *spec0, const char *node0, const char *types0,
}
/* Kernel allows to use MS_RDONLY for bind mounts, but the read-only request
- * could be silently ignored. Check it to avoid 'ro' in mtab and 'rw' in
- * /proc/mounts.
+ * could be silently ignored. Check that and retry with MS_REMOUNT once. If it
+ * is still rw honor it to avoid 'ro' in mtab and 'rw' in /proc/mounts.
*/
if (!fake && mnt5_res == 0 &&
(flags & MS_BIND) && (flags & MS_RDONLY) && !is_readonly(node)) {
-
- printf(_("mount: warning: %s seems to be mounted read-write.\n"), node);
- flags &= ~MS_RDONLY;
+ if (!(flags & MS_REMOUNT)) {
+ flags |= MS_REMOUNT;
+ goto mount_retry;
+ } else {
+ printf(_("mount: warning: %s seems to be mounted read-write.\n"), node);
+ flags &= ~MS_RDONLY;
+ }
}
/* Kernel can silently add MS_RDONLY flag when mounting file system that
--
Kind regards/Mit freundlichen Grüßen, Stefan Tauner
^ permalink raw reply related
* Re: [PATCH] configure.ac : remove enable_foo checks for non-linux OSs
From: Karel Zak @ 2011-02-01 13:05 UTC (permalink / raw)
To: Marek Otahal; +Cc: util-linux
In-Reply-To: <201102011213.23641.markotahal@gmail.com>
On Tue, Feb 01, 2011 at 12:12:45PM +0100, Marek Otahal wrote:
> PS: The TODO list is a good thing, if you write the task more detailed (like
> this one), more people can easily implement it.
OK :-)
> +# we do not build these for non-linux os
> +if test "x$linux_os" = xno
> AC_MSG_WARN([non-linux system; do not build mount utilities])
> build_mount=no
> + AC_MSG_WARN([non-linux system; do not build libmount])
> + build_libmount=no
> + AC_MSG_WARN([non-linux system; do not build switch_root])
> + build_switch_root=no
> + AC_MSG_WARN([non-linux system; do not build pivot_root])
> + build_pivot_root=no
> + AC_MSG_WARN([non-linux system; do not build fallocate])
> + build_fallocate=no
> + AC_MSG_WARN([non-linux system; do not build unshare])
> + build_unshare=no
> fi
This is not exactly what I mean. In your implementation are
Linux-only things disable at all, so if you explicitly
./configure --enable-unshare
then the configure script will ignore this request and unshare(1)
will be disabled. That's wrong (and for some utils is the current
implementation wrong too).
The configure script should not be more smart than user. We need to
care about default settings (if --disable/enable is not specified)
only. Currently the default is "check", I'd like to modify the
default according to $linux_os.
Something like:
linuxonly_default=check
if test "x$linux_os" = xno
AC_MSG_WARN([non-linux system; unshare(1), libmount, ...
are disabled by default. Use --enable-<name>
to enable required util(s)])
linuxonly_default=no
fi
AC_ARG_ENABLE([unshare],
AS_HELP_STRING([--disable-unshare], [do not build unshare]),
[], enable_unshare=$linuxonly_default)
AM_CONDITIONAL(BUILD_UNSHARE, test "x$enable_unshare" != xno)
maybe that for some utils it will be necessary to do some extra
checks before AM_CONDITIONAL() -- for example to detect that systems
has proper syscall (e.g. switch_root depends on openat()).
Note that this is nothing urgent, it's too late for v2.19 release.
Karel
--
Karel Zak <kzak@redhat.com>
http://karelzak.blogspot.com
^ permalink raw reply
* [PATCH] configure.ac : remove enable_foo checks for non-linux OSs
From: Marek Otahal @ 2011-02-01 11:12 UTC (permalink / raw)
To: util-linux; +Cc: Karel Zak
[-- Attachment #1: Type: Text/Plain, Size: 7248 bytes --]
Hello,
I implemented this idea from the TODO list, basically it sets some enable_foo
constants for non-linux systems to "no" at start and then we can skip if-tests
on different places.
From the todo:
build-sys
--------
- we use something like
AC_ARG_ENABLE(...., enable_foo=check)
build_foo=yes
if test "x$enable_foo" = xcheck; then
if test "x$linux_os" = xno; then
build_foo=no
fi
fi
AM_CONDITIONAL(BUILD_LIBMOUNT, test "x$build_foo" = xyes)
for Linux-only utils in configure.ac. It would be nice to set all defaults
for all $enable_ variables at begin of the configure script according to
$linux_os. Something like:
if test "x$linux_os" = xno
enable_mount=no
enable_libmount=no
enable_lsblk=no
fi
then we can remove all "if test "x$enable_foo" = xcheck;" stuff from the
rest
of the configure script.
Thanks, Marek
PS: The TODO list is a good thing, if you write the task more detailed (like
this one), more people can easily implement it.
Signed-off-by: Marek Otahal <markotahal@gmail.com>
---
diff -Nruw util-linux/configure.ac util-linux-mmm/configure.ac
--- util-linux/configure.ac 2011-02-01 00:26:23.603333351 +0100
+++ util-linux-mmm/configure.ac 2011-02-01 11:20:08.860000019 +0100
@@ -334,13 +334,52 @@
AS_HELP_STRING([--disable-mount], [do not build mount utilities]),
[], enable_mount=check
)
-build_mount=yes
-if test "x$enable_mount" = xcheck; then
- if test "x$linux_os" = xno; then
+
+AC_ARG_ENABLE([libmount],
+ AS_HELP_STRING([--disable-libmount], [do not build libmount]),
+ [], enable_libmount=check
+)
+
+C_ARG_ENABLE([switch_root],
+ AS_HELP_STRING([--disable-switch_root], [do not build switch_root]),
+ [], enable_switch_root=check
+)
+
+AC_ARG_ENABLE([pivot_root],
+ AS_HELP_STRING([--disable-pivot_root], [do not build pivot_root]),
+ [], enable_pivot_root=check
+)
+
+AC_ARG_ENABLE([fallocate],
+ AS_HELP_STRING([--disable-fallocate], [do not build fallocate]),
+ [], enable_fallocate=check
+)
+
+AC_ARG_ENABLE([unshare],
+ AS_HELP_STRING([--disable-unshare], [do not build unshare]),
+ [], enable_unshare=check
+)
+
+
+# we do not build these for non-linux os
+if test "x$linux_os" = xno
AC_MSG_WARN([non-linux system; do not build mount utilities])
build_mount=no
+ AC_MSG_WARN([non-linux system; do not build libmount])
+ build_libmount=no
+ AC_MSG_WARN([non-linux system; do not build switch_root])
+ build_switch_root=no
+ AC_MSG_WARN([non-linux system; do not build pivot_root])
+ build_pivot_root=no
+ AC_MSG_WARN([non-linux system; do not build fallocate])
+ build_fallocate=no
+ AC_MSG_WARN([non-linux system; do not build unshare])
+ build_unshare=no
fi
-elif test "x$enable_mount" = xno; then
+
+
+build_mount=yes
+if test "x$enable_mount" = xno; then
build_mount=no
fi
AM_CONDITIONAL(BUILD_MOUNT, test "x$build_mount" = xyes)
@@ -459,17 +498,8 @@
AC_ARG_VAR([BLKID_LIBS_STATIC], [-l options for linking statically with
blkid])
-AC_ARG_ENABLE([libmount],
- AS_HELP_STRING([--disable-libmount], [do not build libmount]),
- [], enable_libmount=check
-)
build_libmount=yes
-if test "x$enable_libmount" = xcheck; then
- if test "x$linux_os" = xno; then
- AC_MSG_WARN([non-linux system; do not build libmount])
- build_libmount=no
- fi
-elif test "x$enable_libmount" = xno; then
+if test "x$enable_libmount" = xno; then
build_libmount=no
fi
@@ -872,19 +902,10 @@
AM_CONDITIONAL(BUILD_CRAMFS, test "x$build_cramfs" = xyes)
-AC_ARG_ENABLE([switch_root],
- AS_HELP_STRING([--disable-switch_root], [do not build switch_root]),
- [], enable_switch_root=check
-)
+build_switch_root=yes
if test "x$enable_switch_root" = xno; then
build_switch_root=no
-else
- build_switch_root=yes
- case $enable_switch_root:$linux_os in
- yes:no) AC_MSG_ERROR([switch_root selected for non-linux system]);;
- check:no) AC_MSG_WARN([non-linux system; do not build switch_root])
- build_switch_root=no;;
- esac
+fi
if test "x$build_switch_root" = xyes; then
case $enable_switch_root:$have_openat in
yes:no) AC_MSG_ERROR([switch_root selected but openat() function not
found]);;
@@ -892,23 +913,13 @@
build_switch_root=no;;
esac
fi
-fi
AM_CONDITIONAL(BUILD_SWITCH_ROOT, test "x$build_switch_root" = xyes)
-AC_ARG_ENABLE([pivot_root],
- AS_HELP_STRING([--disable-pivot_root], [do not build pivot_root]),
- [], enable_pivot_root=check
-)
+build_pivot_root=yes
if test "x$enable_pivot_root" = xno; then
build_pivot_root=no
-else
- build_pivot_root=yes
- case $enable_pivot_root:$linux_os in
- yes:no) AC_MSG_ERROR([pivot_root selected for non-linux system]);;
- check:no) AC_MSG_WARN([non-linux system; do not build pivot_root])
- build_pivot_root=no;;
- esac
+fi
if test "x$build_pivot_root" = xyes; then
case $enable_pivot_root:$util_cv_syscall_pivot_root in
yes:no) AC_MSG_ERROR([pivot_root selected but pivot_root syscall not
found]);;
@@ -916,23 +927,13 @@
build_pivot_root=no;;
esac
fi
-fi
AM_CONDITIONAL(BUILD_PIVOT_ROOT, test "x$build_pivot_root" = xyes)
-AC_ARG_ENABLE([fallocate],
- AS_HELP_STRING([--disable-fallocate], [do not build fallocate]),
- [], enable_fallocate=check
-)
+build_fallocate=yes
if test "x$enable_fallocate" = xno; then
build_fallocate=no
-else
- build_fallocate=yes
- case $enable_fallocate:$linux_os in
- yes:no) AC_MSG_ERROR([fallocate selected for non-linux system]);;
- check:no) AC_MSG_WARN([non-linux system; do not build fallocate])
- build_fallocate=no;;
- esac
+fi
if test "x$build_fallocate" = xyes; then
case $enable_fallocate:$util_cv_syscall_fallocate in
yes:no) AC_MSG_ERROR([fallocate selected but fallocate syscall not
found]);;
@@ -940,23 +941,13 @@
build_fallocate=no;;
esac
fi
-fi
AM_CONDITIONAL(BUILD_FALLOCATE, test "x$build_fallocate" = xyes)
-AC_ARG_ENABLE([unshare],
- AS_HELP_STRING([--disable-unshare], [do not build unshare]),
- [], enable_unshare=check
-)
+build_unshare=yes
if test "x$enable_unshare" = xno; then
build_unshare=no
-else
- build_unshare=yes
- case $enable_unshare:$linux_os in
- yes:no) AC_MSG_ERROR([unshare selected for non-linux system]);;
- check:no) AC_MSG_WARN([non-linux system; do not build unshare])
- build_unshare=no;;
- esac
+fi
if test "x$build_unshare" = xyes; then
case $enable_unshare:$util_cv_syscall_unshare in
yes:no) AC_MSG_ERROR([unshare selected but unshare syscall not found]);;
@@ -964,11 +955,9 @@
build_unshare=no;;
esac
fi
-fi
AM_CONDITIONAL(BUILD_UNSHARE, test "x$build_unshare" = xyes)
-
AC_ARG_ENABLE([elvtune],
AS_HELP_STRING([--enable-elvtune], [build elvtune (only works with 2.2 and
2.4 kernels)]),
[], enable_elvtune=no
--
Marek Otahal :o)
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: sfdisk enhancement proposal - offset/shift support
From: Przemysław 'Przemoc' Pawełczyk @ 2011-01-14 15:45 UTC (permalink / raw)
To: Forest Bond; +Cc: util-linux
In-Reply-To: <20110114142012.GA26786@alittletooquiet.net>
2011/1/14 Forest Bond <forest@alittletooquiet.net>:
> On Fri, Jan 14, 2011 at 02:31:55PM +0100, Przemysław 'Przemoc' Pawełczyk wrote:
>> I have following suggestion for sfdisk:
>> - adding offset/shift support for cumbersome raw disk images (like
>> fixed-size VDI), that don't start at the beginning of the file.
>>
>> Required changes?
>> IMO straightforward way is just adding another option (below is an
>> example), global variable (e.g. shift) and fixing sseek() code and
>> R.total_size in get_geometry() to take it into account.
>>
>> -t# [or --offset #] ignore the number of bytes at the beginning
>
> Isn't this something you can just use a loopback device for?
>
> losetup -f -o $offset $image
To some degree -- yes. It requires BLK_DEV_LOOP (Loopback device
support) built-in in the kernel or compiled as a module though. This
is IMHO unneeded kernel dependency that can be avoided.
Regards.
P.S. mount() and umount() should have their own capability, because
requiring CAP_SYS_ADMIN is pretty insane. But it's not the scope of
this ML.
--
Przemysław 'Przemoc' Pawełczyk
http://przemoc.net/
^ permalink raw reply
* Re: sfdisk enhancement proposal - offset/shift support
From: Forest Bond @ 2011-01-14 14:20 UTC (permalink / raw)
To: Przemysław 'Przemoc' Pawełczyk; +Cc: util-linux
In-Reply-To: <AANLkTimJJDm-9vu_xcMjh0uQSghZE44Miz1XaHcx=p7j@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 762 bytes --]
Hi,
On Fri, Jan 14, 2011 at 02:31:55PM +0100, Przemysław 'Przemoc' Pawełczyk wrote:
> I have following suggestion for sfdisk:
> - adding offset/shift support for cumbersome raw disk images (like
> fixed-size VDI), that don't start at the beginning of the file.
>
> Required changes?
> IMO straightforward way is just adding another option (below is an
> example), global variable (e.g. shift) and fixing sseek() code and
> R.total_size in get_geometry() to take it into account.
>
> -t# [or --offset #] ignore the number of bytes at the beginning
Isn't this something you can just use a loopback device for?
losetup -f -o $offset $image
Thanks,
Forest
--
Forest Bond
http://www.alittletooquiet.net
http://www.pytagsfs.org
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* sfdisk enhancement proposal - offset/shift support
From: Przemysław 'Przemoc' Pawełczyk @ 2011-01-14 13:31 UTC (permalink / raw)
To: util-linux
Hello,
I have following suggestion for sfdisk:
- adding offset/shift support for cumbersome raw disk images (like
fixed-size VDI), that don't start at the beginning of the file.
Required changes?
IMO straightforward way is just adding another option (below is an
example), global variable (e.g. shift) and fixing sseek() code and
R.total_size in get_geometry() to take it into account.
-t# [or --offset #] ignore the number of bytes at the beginning
FWIW such option is rather useless for working on many files at the
same time, unless offsets are really the same. In case of fixed-size
VDI, offset depends on the image size.
Alternatives?
Some time ago I wrote a simple workaround for fixed-size VDIs (doing a
bit more than is needed here, i.e. finding also an offset of the raw
disk image) using LD_PRELOAD technique. It can be found here:
https://gist.github.com/571086. Now I think that having plain offset
option in sfdisk would be still useful. I even regret that I did not
mail about it back then in 2009, because maybe it would be available
in sfdisk for a long time already...
Anyway I'd like to know your opinions before making any patches. After
all I am not sure whether such functionality is acceptable in sfdisk
according to your rules.
Regards.
P.S. Please CC me (I am not on the list).
--
Przemysław 'Przemoc' Pawełczyk
http://przemoc.net/
^ permalink raw reply
* Re: fdisk change proposal - fdisk (util-linux-ng 2.14)
From: Jon Grant @ 2011-01-01 21:05 UTC (permalink / raw)
To: util-linux-ng
Just replying about his proposed change I suggested back in 2009:
I could not find the email, but it is archived online:
http://marc.info/?l=util-linux-ng&m=123815185328131&w=2
I will create a patch to eliminate the warning when a new disklabel
has been created. Caused by use of the "o" command, or also a new
bank disc which is filled with zeros (no disklabel present)
Current version has -h and -v, but not --help and --version. So I will
have a look at adding those two additional options.
I will endeavour to submit a patch soon. Please let me know if there
are any changes I should make to my plan for this patch!
Please include my email address in any replies.
Best regards, Jon
^ permalink raw reply
* Re: NTFS volume label not found due to endian conversion bug in libblkid
From: Andrew Nayenko @ 2010-12-04 11:22 UTC (permalink / raw)
To: util-linux
In-Reply-To: <20101203143031.GJ3077@nb.net.home>
>> I've been having a problem with blkid not finding the volume label
>> on NTFS volumes on my big-endian (PowerPC) system. I tracked the
>> issue down to a bug in the endian conversion code for parsing the
>> MFT $Volume attributes in ntfs.c.
>
> Fixed. Thanks!
Another similar typo:
diff --git a/shlibs/blkid/src/superblocks/nilfs.c b/shlibs/blkid/src/superblocks/nilfs.c
index bf16918..1f8f3a6 100644
--- a/shlibs/blkid/src/superblocks/nilfs.c
+++ b/shlibs/blkid/src/superblocks/nilfs.c
@@ -84,7 +84,7 @@ static int probe_nilfs2(blkid_probe pr, const struct blkid_idmag *mag)
if (!sb)
return -1;
- bytes = le32_to_cpu(sb->s_bytes);
+ bytes = le16_to_cpu(sb->s_bytes);
crc = crc32(le32_to_cpu(sb->s_crc_seed), (unsigned char *)sb, sumoff);
crc = crc32(crc, sum, 4);
crc = crc32(crc, (unsigned char *)sb + sumoff + 4, bytes - sumoff - 4);
--
I believe there is a better approach to endianness handling. And compiler is our best
helper here. We just need to make it generate an error when we try to use a field with
wrong (or without any) endianness conversion. To achieve this, fields in structures
should be explicitly declared as little or big endian, e.g.:
struct sb {
.....
xle16_t s_bytes;
.....
};
The xle16_t type should be a complex one, not an integral:
typedef struct { uint16_t __leu16; } xle16_t;
Only appropriate conversion functions should know how to convert those types to
integral ones:
uint16_t xle16_to_cpu(xle16_t v) { return le16_to_cpu(v.__leu16); }
xle16_t xcpu_to_le16(uint16_t v) { xle16_t t = {cpu_to_le16(v)}; return t; }
That's it. Now compiler will enforce us to use the right conversion anytime we
access a field, i.e. the following statements will fail to compile:
uint16_t bytes = sb->s_bytes; /* no conversion */
uint32_t bytes = xle32_to_cpu(sb->s_bytes); /* wrong conversion */
I use this approach in a real life project (FS driver) and it proved to be a good
"bugkeeper".
I had a look at shlibs/blkid/src/superblocks/*.c and I think that most probers can
adopt this approach. But in some cases it can be problematic:
1) sometimes fields endianness can vary (e.g. befs, linux_raid) and we do not know
it at compile time;
2) some probers (zfs) prefer to convert fields to native endianness first and then
just use instead of in-place conversion at any access to the field.
--
Andrew Nayenko <resver@gmail.com>
^ permalink raw reply related
* losetup -e 1 -p fd doesn't work
From: David Barksdale @ 2010-11-17 1:04 UTC (permalink / raw)
To: util-linux-ng
Why does losetup use getpass() for LO_CRYPT_XOR but xgetpass()
otherwise? Is this some devious plot to compel people to stop using
XOR?
--
David Barksdale
Adcedo Solutions
+1-425-214-4901
^ permalink raw reply
* Re: NFS remount bug
From: Karel Zak @ 2010-10-22 20:57 UTC (permalink / raw)
To: Chuck Lever; +Cc: util-linux-ng
In-Reply-To: <9706D446-5B62-42FC-A3D7-23046AB96822@oracle.com>
On Fri, Oct 22, 2010 at 04:14:53PM -0400, Chuck Lever wrote:
> This is documented in
>
> https://bugzilla.linux-nfs.org/show_bug.cgi?id=188
>
> There are some interesting test results posted there.
>
> This looks like behavior that is totally controlled by mount(8),
> since mount(8) passes the correct options to mount.nfs in some
> cases, and sometimes it doesn't.
Yes (but it does not mean that you cannot read the original options
from mtab in mount.nfs).
> If the mount point is not already in /etc/fstab, and the remount
> command line does not include the "device" (it looks like "mount -o
> remount,foo /mntdir") then it gets it right (that is, it adds the
> correct set of mount options back to /etc/mtab). Other combinations
> don't get it right.
>
> Is there a reason why the set of mount options that appear in
> /etc/mtab should be different depending on how the remount command
> is specified and whether the mount point appears in /etc/fstab? Any
> chance this can be made to work consistently in each of these cases?
>
> Thanks for any advice, or history lessons.
This is old and documented behaviour. There is not a difference
between remount and normal mount.
# mount <source> <target>
means that you want to bypass fstab (mount(8) has all necessary
information on command line), but
# mount <source> | <target>
means that you have to use fstab (command line does not contain all
information).
If fstab does not contain <source> or <target> then it lookups mtab,
it's was probably added because
# mount /dev/sda1 /mnt
# mount -o remount,ro /mnt
is expected to work independently on fstab.
I see only one problem -- many many years ago there probably wasn't
difference between mount options in fstab and mtab, so it was correct
to lookup fstab before mtab on remount. This is problem now.
IMHO mount(8) should be fixed to read mount options only from mtab
on remount. The fstab file should be ignore at all.
Karel
--
Karel Zak <kzak@redhat.com>
http://karelzak.blogspot.com
^ permalink raw reply
* Re: NFS remount bug
From: Chuck Lever @ 2010-10-22 20:14 UTC (permalink / raw)
To: kzak; +Cc: util-linux-ng
In-Reply-To: <6BEE826D-5AC3-4CA7-A954-6255A6BD7AED@oracle.com>
On Oct 19, 2010, at 1:32 PM, Chuck Lever wrote:
> Hi-
>
> I'm working on the NFS submount commands. These are found in the nfs-utils package, but they inherited a bunch of code from utils-linux to read fstab and manage mtab.
>
> We've got a little problem with "-o remount".
>
> At mount time, mount.nfs can negotiate with the target NFS server to determine how to contact it to send the MNT request and set up the communication parameters for the NFS protocol. If the mount process succeeds, mount.nfs puts the command line options in /etc/mtab.
>
> At umount time, umount.nfs reads these options back from /etc/mtab so that it can figure out how to send a UMNT request. There are some problem cases, though.
>
> If /etc/mtab is a link to /proc/mounts, the final fixed negotiated options appear there, not necessarily what was on the command line. If the server reboots, some of those options might become stale.
>
> If a remount is done, the options in /etc/mtab are wiped, so umount.nfs has no way to know how to contact the server.
>
> We also know that everyone wants to toss /etc/mtab.
>
> So: what future-proof mechanism do we use to preserve the mount command line so umount.nfs has a chance of working reliably?
>
> In the meantime, is there a straightforward way to merge the old and new mount options during a remount?
This is documented in
https://bugzilla.linux-nfs.org/show_bug.cgi?id=188
There are some interesting test results posted there.
This looks like behavior that is totally controlled by mount(8), since mount(8) passes the correct options to mount.nfs in some cases, and sometimes it doesn't.
If the mount point is not already in /etc/fstab, and the remount command line does not include the "device" (it looks like "mount -o remount,foo /mntdir") then it gets it right (that is, it adds the correct set of mount options back to /etc/mtab). Other combinations don't get it right.
Is there a reason why the set of mount options that appear in /etc/mtab should be different depending on how the remount command is specified and whether the mount point appears in /etc/fstab? Any chance this can be made to work consistently in each of these cases?
Thanks for any advice, or history lessons.
--
chuck[dot]lever[at]oracle[dot]com
^ permalink raw reply
* NFS remount bug
From: Chuck Lever @ 2010-10-19 17:32 UTC (permalink / raw)
To: util-linux-ng
Hi-
I'm working on the NFS submount commands. These are found in the nfs-utils package, but they inherited a bunch of code from utils-linux to read fstab and manage mtab.
We've got a little problem with "-o remount".
At mount time, mount.nfs can negotiate with the target NFS server to determine how to contact it to send the MNT request and set up the communication parameters for the NFS protocol. If the mount process succeeds, mount.nfs puts the command line options in /etc/mtab.
At umount time, umount.nfs reads these options back from /etc/mtab so that it can figure out how to send a UMNT request. There are some problem cases, though.
If /etc/mtab is a link to /proc/mounts, the final fixed negotiated options appear there, not necessarily what was on the command line. If the server reboots, some of those options might become stale.
If a remount is done, the options in /etc/mtab are wiped, so umount.nfs has no way to know how to contact the server.
We also know that everyone wants to toss /etc/mtab.
So: what future-proof mechanism do we use to preserve the mount command line so umount.nfs has a chance of working reliably?
In the meantime, is there a straightforward way to merge the old and new mount options during a remount?
--
chuck[dot]lever[at]oracle[dot]com
^ permalink raw reply
* Re: [mount] --bind -o suid/exec/...
From: Stephane Chazelas @ 2010-02-09 17:09 UTC (permalink / raw)
To: Karel Zak; +Cc: util-linux-ng
In-Reply-To: <20100209162305.GG6375@nb.net.home>
2010-02-09 17:23:05 +0100, Karel Zak:
[...]
> > mount --bind /here /there
> > mount -o remount,noexec /there
[...]
> >, or better, "mount" could
> > be changed so that one can do it in a single step with:
> >
> > mount --bind -o noexec /here /there
>
> this is unsupported by kernel, the "remount" and "bind" are two
> different operations.
[...]
Thanks Karel,
but what about changing mount(8) so that it does two mount(2)s
upon --bind -o?
One thing I've not mentionned is that it makes it quite awkward
to add it in /etc/fstab.
/here /there none bind 0 0
there-remount /there none remount,noexec 0 0
works with mount -a but not with Ubuntu's mountall(8) for
instance.
Cheers,
Stephane
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox