Ext3 filesystem info?
Alex
Thanks.
Alex
-----Original Message-----
From: owner-linux-...@vger.rutgers.edu
<owner-linux-...@vger.rutgers.edu>
To: linux-ker...@vger.rutgers.edu
<linux-ker...@vger.rutgers.edu>
Date: Thursday, September 16, 1999 10:49 AM
Subject: linux-kernel-digest V1 #4467
>
>linux-kernel-digest Thursday, 16 September 1999 Volume 01 : Number
4467
>
>In this issue:
>
> Re: Linux 2.3.18ac5
> SB PnP IDE driver
> Re: ext2 file sizes
> 2.3.18ac[4] PCMCIA...
> Re: problem with system clock
> Re: NFS problem: __nfs_fhget: inode still busy
> Re: ext2 file sizes
> Re: problem with system clock
> Re: ext2 file sizes
> /proc/bus/usb/000 will not work correctly when usb is compiled into kernel
> Re: 2.3.18ac[4] PCMCIA...
> Re: ext2 file sizes
> Re: Linux 2.3.18ac5
> strange mounting problem
> [patch] __flush_one_page() on i386
> Re: [patch] __flush_one_page() on i386
> Symbios DAC960 and Quad Xeon
> Re: ext2 file sizes
> Re: State of USB drivers
> Re: 2.2.12: serial driver swapping characters?
> [PATCH] console alertness - notifying of console activities
> Email subject line
> Re: Mouse input corrupted under X 3.3.3.1 with kernel 2.2.12
> > 15K simultaneous connections EXAMPLE program/OS config needed, was: Re:
POSIX aio vs completion ports
> Re: [patch] __flush_one_page() on i386
> Re: Email subject line
> Re: Email subject line
> Re: Resource Limits Architecture
> Re: Email subject line
> oops when insmodding msp3400, bttv 0.6.4, linux 2.2.12
> 2.2.18ac5 NFS client bug
> Problem in inserting module
> Re: Lockups - lost interrupt
>
>See the end of the digest for information on subscribing to the
linux-kernel
>or linux-kernel-digest mailing lists.
>
>----------------------------------------------------------------------
>
>From: Richard Guenther <zxm...@student.uni-tuebingen.de>
>Date: Thu, 16 Sep 1999 12:04:24 +0200 (METDST)
>Subject: Re: Linux 2.3.18ac5
>
>On Thu, 16 Sep 1999, Alan Cox wrote:
>
>>
>> Ok give this a spin. We need to sort out the modules/setup argument thing
yet.
>
>Note that a fix using MODULE_NAME() _will_ break the current semantics
>of some modules:
>- - we (really) should enforce everyone to have a MODULE_NAME (can we get
> a default out of __FILE_NAME__ with some tricky macro??)
>- - some already have a prefix encoded into their arguments (isapnp springs
> into my mind) - those will have to be ripped off - and it "breaks"
> backward-compatibility, as the prefixes are not always like "isapnp_"
>
>now, well if its easy, I'll look into it.
>
>Richard.
>
>
>- --
>Richard Guenther <richard....@student.uni-tuebingen.de>
>PGP: 2E829319 - 2F 83 FC 93 E9 E4 19 E2 93 7A 32 42 45 37 23 57
>WWW: http://www.anatom.uni-tuebingen.de/~richi/
>
>
>Please read the FAQ at http://www.tux.org/lkml/
>
>------------------------------
>
>From: Antonio Miguel Ferreira Marques Trindade
<trin...@student.dei.uc.pt>
>Date: Thu, 16 Sep 1999 11:17:20 +0100 (WET DST)
>Subject: SB PnP IDE driver
>
> Now that the kernel has ISA PnP support, is it going to be possible to
>use the IDE port on this card? I am desperatly needing one more IDE port
>so in addition to my already filled 4. I tried over and over to put the
>IDE driver in a module and boot the system through the initrd method but
>without success and I REALLY NEED that IDE port working?
>
>- --
> Regards,
> Antonio Trindade.
>
>/--------------------------------------------------------------------------
-\
>|Timor Loro Sae will prevail!!! | F.C.T. da Universidade de Coimbra
|
>|ux RuleZ Linux RuleZ Linux Rule| Antonio Miguel Ferreira Marques Trindade
|
>|-------------------------------| PGP Public key available by finger
|
>|Jean-Michel Jarre is very cool!| Coimbra, PORTUGAL |
>|--------------------------------------------------------------------------
-|
>| E-mail address: trin...@student.dei.uc.pt |S/2 OS/2 OS/2 OS/2 OS/2 OS/2
O|
>\--------------------------------------------------------------------------
-/
>
>
>Please read the FAQ at http://www.tux.org/lkml/
>
>------------------------------
>
>From: David Weinehall <t...@acc.umu.se>
>Date: Thu, 16 Sep 1999 12:31:38 +0200 (MET_DST)
>Subject: Re: ext2 file sizes
>
>On Thu, 16 Sep 1999, Alexander Kjeldaas wrote:
>
>> On Wed, Sep 15, 1999 at 11:48:07AM -0400, Blankenship, Keith wrote:
>> > I am having some difficulty with the ext2 file systems. I need to
generate a
>> > file that will be > 5 Gigabytes, and there appears to be a file size
cap at
>> > approximately 2 Gig. I am running what appears to be a version 2.0.36
>> > Kernel. Is there anything I can adjust, or do to increase the maximum
file
>> > size? Or is there a newer kernel that may work?
>> >
>>
>> You will have to run another OS like FreeBSD for this to work - or
>> wait for Linux to catch up. Which will probably take some time.
>
>I'd say no on both claims here.
>
>a.) (most simple solution) Get an Alpha, Sparc64 or Power64 (not PPC)
>based machine
>b.) I don't believe Matti Aarnio's patches are too far away...
>
>Of course, at least for video & audio, using Raw-IO would probably be a
>third alternative.
>
>/David
> _ _
> // David Weinehall <t...@acc.umu.se> /> Northern lights wander \\
>// Project MCA Linux hacker // Dance across the winter sky //
>\> http://www.acc.umu.se/~tao/ </ Full colour fire </
>
>
>
>Please read the FAQ at http://www.tux.org/lkml/
>
>------------------------------
>
>From: John Michael Clemens <cle...@rpi.edu>
>Date: Thu, 16 Sep 1999 06:33:21 -0400 (EDT)
>Subject: 2.3.18ac[4] PCMCIA...
>
>what is the status of the PCMCIA merge? I can't seem to get 2.3.18ac4 to
>compile on my laptop, and it's barfing on the pcmcia code in
>drivers/pcmcia (i have it trying to compile in, and not as a module).
>After changing some things in the makefile in that directory, it compiled
>and built a pcmcia_core.o file. But on linking the entire kernel, it
>seemed to be looking for a pcmcia.o file in that directory which does not
>exist. Haven't tried it as a module yet....
>
>Any pointers? Alan?
>
>john.c
>
>- - --
>/* John Clemens http://www.rpi.edu/~clemej _/ I like cats too, */
>/* ICQ: 7175925 cle...@rpi.edu _/ Lets exchange recipies */
>/* RPI Comp. Eng. 2000, Linux Parllel/Network/OS/Driver Specialist */
>
>
>Please read the FAQ at http://www.tux.org/lkml/
>
>------------------------------
>
>From: Andrea Arcangeli <and...@suse.de>
>Date: Thu, 16 Sep 1999 12:33:44 +0200 (CEST)
>Subject: Re: problem with system clock
>
>On Thu, 16 Sep 1999, Herbert Huber wrote:
>
>>motherboard used is an ASUS P2B-DF. Trying to set the BIOS clock via
>>the /sbin/clock or the /sbin/hwclock
>>commands fail. As probable reason for this behaviour the syslog file is
>>full of entries like:
>>
>>Sep 16 07:31:23 lxsrv2 kernel: set_rtc_mmss: can't update from 50 to 1
>>Sep 16 07:32:24 lxsrv2 kernel: set_rtc_mmss: can't update from 50 to 2
>>Sep 16 07:33:25 lxsrv2 kernel: set_rtc_mmss: can't update from 50 to 3
>>Sep 16 07:34:26 lxsrv2 kernel: set_rtc_mmss: can't update from 50 to 4
>
>You forgot to specify that you are running ntpd ;). It's a SMP race
somewhere.
>I didn't gone into that yet.
>
>Andrea
>
>
>Please read the FAQ at http://www.tux.org/lkml/
>
>------------------------------
>
>From: Paul Jakma <pa...@clubi.ie>
>Date: Thu, 16 Sep 1999 11:36:47 +0100 (IST)
>Subject: Re: NFS problem: __nfs_fhget: inode still busy
>
>Hi Trond.
>
>Thanks for the patch. I'll give it a go as soon as i can.
>
>Incidentally, how does the stale inode persist across reboots? I
>presume it must be cached somewhere? But where? I've cleared out the
>server's state cache, and i don't know where it could be cached on
>the client.
>
>thanks,
>
>Paul Jakma.
>
>On 16 Sep 1999, Trond Myklebust wrote:
>
> Paul Jakma <pa...@clubi.ie> writes:
>
> > I have an nfs client which virtually hangs immediately after boot. it
> > continually prints out the message:
> >
> > __nfs_fhget: inode 8227 still busy, i_count=1
> >
> > This happens just after finishing executing rc.local. (RH5 boot-up
> > scripts). It's then supposed to start xdm, but never get's that far.
> > Inode number is always the same.
>
> This is due to the stale inode code getting activated, and trying to
> clean out an inode that is in use. I have a patch which softens the
> stale inode code which may (or may not) help.
>
> Please try it out and see if it helps...
>
> Cheers,
> Trond
>
> diff -u --recursive --new-file linux-2.2.12.orig/fs/dcache.c
linux-2.2.12/fs/dcache.c
> --- linux-2.2.12.orig/fs/dcache.c Mon Apr 26 08:17:56 1999
> +++ linux-2.2.12/fs/dcache.c Mon Aug 30 16:13:24 1999
> @@ -168,6 +168,11 @@
> int d_invalidate(struct dentry * dentry)
> {
> /*
> + * If it's already been dropped, return OK.
> + */
> + if (&list_empty(&dentry->d_hash))
> + return 0;
> + /*
> * Check whether to do a partial shrink_dcache
> * to get rid of unused child entries.
> */
> diff -u --recursive --new-file linux-2.2.12.orig/fs/nfs/dir.c
linux-2.2.12/fs/nfs/dir.c
> --- linux-2.2.12.orig/fs/nfs/dir.c Mon Aug 9 21:04:57 1999
> +++ linux-2.2.12/fs/nfs/dir.c Mon Aug 30 16:15:54 1999
> @@ -395,13 +395,14 @@
> * If mtime is close to present time, we revalidate
> * more often.
> */
> +#define NFS_REVALIDATE_NEGATIVE (1 * HZ)
> static inline int nfs_neg_need_reval(struct dentry *dentry)
> {
> - unsigned long timeout = 30 * HZ;
> + unsigned long timeout = NFS_ATTRTIMEO(dentry->d_parent->d_inode);
> long diff = CURRENT_TIME - dentry->d_parent->d_inode->i_mtime;
>
> - if (diff < 5*60)
> - timeout = 1 * HZ;
> + if (diff < 5*60 && timeout > NFS_REVALIDATE_NEGATIVE)
> + timeout = NFS_REVALIDATE_NEGATIVE;
>
> return time_after(jiffies, dentry->d_time + timeout);
> }
> @@ -462,12 +463,8 @@
> goto out_bad;
>
> /* Filehandle matches? */
> - if (memcmp(dentry->d_fsdata, &fhandle, sizeof(struct nfs_fh))) {
> - if (!list_empty(&dentry->d_subdirs))
> - shrink_dcache_parent(dentry);
> - if (dentry->d_count < 2)
> - goto out_bad;
> - }
> + if (memcmp(dentry->d_fsdata, &fhandle, sizeof(struct nfs_fh)))
> + goto out_bad;
>
> /* Ok, remeber that we successfully checked it.. */
> nfs_renew_times(dentry);
> @@ -476,6 +473,9 @@
> out_valid:
> return 1;
> out_bad:
> + d_drop(dentry);
> + if (!list_empty(&dentry->d_subdirs))
> + shrink_dcache_parent(dentry);
> if (dentry->d_parent->d_inode)
> nfs_invalidate_dircache(dentry->d_parent->d_inode);
> if (inode && S_ISDIR(inode->i_mode))
> diff -u --recursive --new-file linux-2.2.12.orig/fs/nfs/inode.c
linux-2.2.12/fs/nfs/inode.c
> --- linux-2.2.12.orig/fs/nfs/inode.c Mon Aug 9 21:05:05 1999
> +++ linux-2.2.12/fs/nfs/inode.c Mon Aug 30 16:14:37 1999
> @@ -492,6 +492,48 @@
> }
>
> /*
> + * The following may seem pretty minimal, but the stateless nature
> + * of NFS means that we can't do too much more. Previous attempts to use
> + * fattr->nlink to determine how well the cached state matches the
> + * server suffer from races with stale dentries. You also risk killing
> + * off processes by just doing 'mv file newdir' on the server.
> + *
> + * FIXME: Of course, if 2 exported files have the same fileid (but
> + * different fsid which makes it legal) you're still buggered...
> + * Trond, August 1999.
> + */
> +static int
> +nfs_inode_is_stale(struct inode *inode, struct nfs_fattr *fattr)
> +{
> + int unhashed;
> + int is_stale = 0;
> +
> + if (inode->i_mode &&
> + (fattr->mode & S_IFMT) != (inode->i_mode & S_IFMT))
> + is_stale = 1;
> +
> + if (is_bad_inode(inode))
> + is_stale = 1;
> +
> + /*
> + * Free up unused cached dentries to see if it's wise to unhash
> + * the inode (which we can do if all the dentries have been unhashed).
> + */
> + unhashed = nfs_free_dentries(inode);
> +
> + /* Assume we're holding 1 lock on the inode from 'iget'
> + *
> + * NB: sockets sometimes have volatile file handles
> + * don't invalidate their inodes even if all dentries are
> + * unhashed. */
> + if (unhashed && inode->i_count == unhashed + 1
> + && !S_ISSOCK(inode->i_mode) && !S_ISFIFO(inode->i_mode))
> + is_stale = 1;
> +
> + return is_stale;
> +}
> +
> +/*
> * This is our own version of iget that looks up inodes by file handle
> * instead of inode number. We use this technique instead of using
> * the vfs read_inode function because there is no way to pass the
> @@ -550,53 +592,26 @@
> static struct inode *
> __nfs_fhget(struct super_block *sb, struct nfs_fattr *fattr)
> {
> - struct inode *inode;
> - int max_count, stale_inode, unhashed = 0;
> + struct inode *inode = NULL;
>
> -retry:
> - inode = iget(sb, fattr->fileid);
> - if (!inode)
> + if (!fattr)
> goto out_no_inode;
> - /* N.B. This should be impossible ... */
> - if (inode->i_ino != fattr->fileid)
> - goto out_bad_id;
>
> - /*
> - * Check for busy inodes, and attempt to get rid of any
> - * unused local references. If successful, we release the
> - * inode and try again.
> - *
> - * Note that the busy test uses the values in the fattr,
> - * as the inode may have become a different object.
> - * (We can probably handle modes changes here, too.)
> - */
> - stale_inode = inode->i_mode &&
> - ((fattr->mode ^ inode->i_mode) & S_IFMT);
> - stale_inode |= inode->i_count && inode->i_count == unhashed;
> - max_count = S_ISDIR(fattr->mode) ? 1 : fattr->nlink;
> - if (stale_inode || inode->i_count > max_count + unhashed) {
> - dprintk("__nfs_fhget: inode %ld busy, i_count=%d, i_nlink=%d\n",
> - inode->i_ino, inode->i_count, inode->i_nlink);
> - unhashed = nfs_free_dentries(inode);
> - if (stale_inode || inode->i_count > max_count + unhashed) {
> - printk("__nfs_fhget: inode %ld still busy, i_count=%d\n",
> - inode->i_ino, inode->i_count);
> - if (!list_empty(&inode->i_dentry)) {
> - struct dentry *dentry;
> - dentry = list_entry(inode->i_dentry.next,
> - struct dentry, d_alias);
> - printk("__nfs_fhget: killing %s/%s filehandle\n",
> - dentry->d_parent->d_name.name,
> - dentry->d_name.name);
> - memset(dentry->d_fsdata, 0,
> - sizeof(struct nfs_fh));
> - }
> - remove_inode_hash(inode);
> - nfs_invalidate_inode(inode);
> - unhashed = 0;
> - }
> + while (!inode) {
> + inode = iget(sb, fattr->fileid);
> + if (!inode)
> + goto out_no_inode;
> + /* N.B. This should be impossible ... */
> + if (inode->i_ino != fattr->fileid)
> + goto out_bad_id;
> +
> + if (!nfs_inode_is_stale(inode,fattr))
> + break;
> +
> + remove_inode_hash(inode);
> + nfs_invalidate_inode(inode);
> iput(inode);
> - goto retry;
> + inode = NULL;
> }
> nfs_fill_inode(inode, fattr);
> dprintk("NFS: __nfs_fhget(%x/%ld ct=%d)\n",
> fh = (u32 *) &fhandle;
> dfprintk(PAGECACHE, " %08x%08x%08x%08x%08x%08x%08x%08x\n",
> @@ -751,6 +766,8 @@
> fh[0],fh[1],fh[2],fh[3],fh[4],fh[5],fh[6],fh[7]);
> + if (!IS_ROOT(dentry))
> + d_drop(dentry);
> goto out;
> }
>
>
>
>
>- --
>Paul Jakma
>pa...@clubi.ie http://hibernia.clubi.ie
>PGP5 key: http://www.clubi.ie/jakma/publickey.txt
>- -------------------------------------------
>Fortune:
>They are called computers simply because computation is the only
significant
>job that has so far been given to them.
>
>
>
>Please read the FAQ at http://www.tux.org/lkml/
>
>------------------------------
>
>From: Matti Aarnio <matti....@sonera.fi>
>Date: Thu, 16 Sep 1999 13:52:42 +0300
>Subject: Re: ext2 file sizes
>
>On Thu, Sep 16, 1999 at 12:31:38PM +0200, David Weinehall wrote:
>.... (using other operating systems than Linux at ia32 system) ....
>> I'd say no on both claims here.
>>
>> a.) (most simple solution) Get an Alpha, Sparc64 or Power64 (not PPC)
>> based machine
>
> Initial condition was stated as: "ia32 system",
> which excludes current 64-bit systems...
>
>> b.) I don't believe Matti Aarnio's patches are too far away...
>>
>> Of course, at least for video & audio, using Raw-IO would probably be a
>> third alternative.
>
> Thanks for the "b", but for grabbing I would (myself) use
> initially raw partition and Raw-IO, then I would pull the
> data out from there in a more leisure pace to normal
> filesystem for non-realtime task of editing -- and for
> the playback I would again drop it into the Raw-IO...
>
> For video playback (and grabbing) nothing really beats
> filesystems with 32-to-256 kB block sizes, and schedulable
> IO. Linux does not have such a beast - so far...
> (Getting extent indexing into EXT2 would allow it to mutate
> towards such wonder animal, though..)
>
> If you want to play some, my LFS things are at:
> ftp://mea.tmt.tele.fi/linux/LFS/
>
>> /David
>> // David Weinehall <t...@acc.umu.se> /> Northern lights wander \\
>
>/Matti Aarnio
>
>Please read the FAQ at http://www.tux.org/lkml/
>
>------------------------------
>
>From: Herbert Huber <Herber...@lrz-muenchen.de>
>Date: Thu, 16 Sep 1999 12:56:01 +0200
>Subject: Re: problem with system clock
>
>Yes, you are right! I惴 running xntpd version xntp-4.0.92c-3. However
>what astonishes me is that my second smp server, running the same kernel
>but having two 450 MHz PII instead of two 500 MHz PIII installed,
>doesnæ„’ have this problem at all. To my knowledge linux-2.2.3 doesnæ„’
>support any special PIII features. So what makes the difference - clock
>rate?
>
>/Herbert
>
>
>Please read the FAQ at http://www.tux.org/lkml/
>
>------------------------------
>
>From: David Weinehall <t...@acc.umu.se>
>Date: Thu, 16 Sep 1999 12:57:08 +0200 (MET_DST)
>Subject: Re: ext2 file sizes
>
>On Thu, 16 Sep 1999, Matti Aarnio wrote:
>
>> On Thu, Sep 16, 1999 at 12:31:38PM +0200, David Weinehall wrote:
>> .... (using other operating systems than Linux at ia32 system) ....
>> > I'd say no on both claims here.
>> >
>> > a.) (most simple solution) Get an Alpha, Sparc64 or Power64 (not PPC)
>> > based machine
>>
>> Initial condition was stated as: "ia32 system",
>> which excludes current 64-bit systems...
>
>Sorry, missed out that one... :/
>
>> > b.) I don't believe Matti Aarnio's patches are too far away...
>> >
>> > Of course, at least for video & audio, using Raw-IO would probably be a
>> > third alternative.
>>
>> Thanks for the "b", but for grabbing I would (myself) use
>> initially raw partition and Raw-IO, then I would pull the
>> data out from there in a more leisure pace to normal
>> filesystem for non-realtime task of editing -- and for
>> the playback I would again drop it into the Raw-IO...
>>
>> For video playback (and grabbing) nothing really beats
>> filesystems with 32-to-256 kB block sizes, and schedulable
>> IO. Linux does not have such a beast - so far...
>> (Getting extent indexing into EXT2 would allow it to mutate
>> towards such wonder animal, though..)
>>
>> If you want to play some, my LFS things are at:
>> ftp://mea.tmt.tele.fi/linux/LFS/
>
>Well... My largest disk at the moment is 200 MB, so...
>
>(I do all kernel-dev at the University)
>
>/David
> _ _
> // David Weinehall <t...@acc.umu.se> /> Northern lights wander \\
>// Project MCA Linux hacker // Dance across the winter sky //
>\> http://www.acc.umu.se/~tao/ </ Full colour fire </
>
>
>Please read the FAQ at http://www.tux.org/lkml/
>
>------------------------------
>
>From: Pavel Machek <pa...@bug.ucw.cz>
>Date: Thu, 16 Sep 1999 12:41:04 +0200
>Subject: /proc/bus/usb/000 will not work correctly when usb is compiled
into kernel
>
>Hi!
>
>Here's patch to make it work. Basically you need to first
>proc_usb_init(), because otherwise it will be unable to register buses
>(/proc/bus/usb/000 will not appear).
>
> Pavel
>
>- --- clean//drivers/usb/usb-core.c Wed Sep 8 20:41:58 1999
>+++ linux/drivers/usb/usb-core.c Thu Sep 16 12:33:29 1999
>@@ -31,6 +31,9 @@
>
> int usb_init(void)
> {
>+#ifdef CONFIG_USB_PROC
>+ proc_usb_init ();
>+#endif
> #ifndef CONFIG_USB_MODULE
> # ifdef CONFIG_USB_UHCI
> uhci_init();
>@@ -68,9 +71,6 @@
> # ifdef CONFIG_USB_SCSI
> usb_scsi_init();
> # endif
>- -#endif
>- -#ifdef CONFIG_USB_PROC
>- - proc_usb_init ();
> #endif
> return 0;
> }
>
>- --
> pa...@suse.cz
>Hi! I'm a .signature virus! Copy me into your ~/.signature, please!
>
>Please read the FAQ at http://www.tux.org/lkml/
>
>------------------------------
>
>From: Alan Cox <al...@lxorguk.ukuu.org.uk>
>Date: Thu, 16 Sep 1999 12:20:19 +0100 (BST)
>Subject: Re: 2.3.18ac[4] PCMCIA...
>
>> drivers/pcmcia (i have it trying to compile in, and not as a module).
>> After changing some things in the makefile in that directory, it compiled
>> and built a pcmcia_core.o file. But on linking the entire kernel, it
>> seemed to be looking for a pcmcia.o file in that directory which does not
>> exist. Haven't tried it as a module yet....
>>
>> Any pointers? Alan?
>
>I test build PCMCIA as a module. If the makefiles arent yet quite right
>Im not suprised
>
>
>Please read the FAQ at http://www.tux.org/lkml/
>
>------------------------------
>
>From: Erik Mouw <J.A.K...@its.tudelft.nl>
>Date: Thu, 16 Sep 99 13:34:21 +0200
>Subject: Re: ext2 file sizes
>
>On Wed, 15 Sep 1999 15:17:47 -0400 (EDT), Richard B. Johnson wrote:
>> What on earth are you doing with a single _file_ of that size? If you
>> need a gob of storage for data acquisition, you might be better off
>> with a dedicated raw device. Since you access it in blocks, rather than
>> bytes, you won't have a size limitation for a few more years.
>
>Recording studio quality uncompressed digital video (CCIR 601:
>720x576@25Hz YUV 4:2:2; ~20 Mbyte per second[1]) for example. One minute of
>video already uses ~1.2 Gbyte. It's much easier to record it to a normal
>filesystem[2] instead of a raw device: you can use the standard libc file
>functions to manipulate the data.
>
>
>Erik
>
>[1] 720 pixels horizontal x 576 pixels vertical x 2 bytes per pixel + 6144
> bytes padding to get to the nearest multiple of 16 kbyte (for
> performance reasons) = 835584 bytes per frame.
>[2] Although you can hardly call SGI IRIX XFS with real-time partitions
> and guaranteed rate I/O a "normal filesystem".
>
>- --
>J.A.K. (Erik) Mouw, Information and Communication Theory Group, Department
>of Electrical Engineering, Faculty of Information Technology and Systems,
>Delft University of Technology, PO BOX 5031, 2600 GA Delft, The
Netherlands
>Phone: +31-15-2785859 Fax: +31-15-2781843 Email J.A.K...@its.tudelft.nl
>WWW: http://www-ict.its.tudelft.nl/~erik/
>
>
>
>Please read the FAQ at http://www.tux.org/lkml/
>
>------------------------------
>
>From: Alan Cox <al...@lxorguk.ukuu.org.uk>
>Date: Thu, 16 Sep 1999 12:36:47 +0100 (BST)
>Subject: Re: Linux 2.3.18ac5
>
>> Note that a fix using MODULE_NAME() _will_ break the current semantics
>> of some modules:
>> - we (really) should enforce everyone to have a MODULE_NAME (can we get
>> a default out of __FILE_NAME__ with some tricky macro??)
>
>I'd rather enforce it. I can go through and put all the module name's in
>pretty fast if someone puts the base code together and gets it working
>for a few items
>
>> - some already have a prefix encoded into their arguments (isapnp springs
>> into my mind) - those will have to be ripped off - and it "breaks"
>> backward-compatibility, as the prefixes are not always like "isapnp_"
>
>I think we only break compatibility with 2.0 modules
>>
>> now, well if its easy, I'll look into it.
>
>Ok
>
>
>Please read the FAQ at http://www.tux.org/lkml/
>
>------------------------------
>
>From: Andreas Tobler <t...@pop.agri.ch>
>Date: Thu, 16 Sep 1999 13:51:21 +0200
>Subject: strange mounting problem
>
>Hi,
>
>the subject I struggled over this thing is still my not working
>MO-drive. I sat down to extensivly test the conditions when and how my
>Optical behaves when mounting it.
>As said earlier this is an older Optical drive with SCSI revision: 01 CCS
>I booted with media inserted.
>
>Then I mounted the device via 'hand' means: mount /dev/sdc <mountpoint>
>and NOT mount <mountpoint> which is written in fstab.
>Ok, behaves ok.
>Now umounting the drive and ejecting it.
>Mount an empty drive (no cartridge in) with mount /dev/sdc <mountpoint>
>gives a few errors, ok.
>Umount the empty drive.
>gives a few errors, same as above, ok.
>Mount an empty drive with mount /dev/sdc <mountpoint>
>gives a few more errors.
>Umount the empty drive.
>umount: /dev/sdc: not found, ok.
>
>Now I change the side of the cartridge and do the same again.
>Doing so I get the correct content listed from Bside.
>
>In short I can see my A and Bside of the MO-media when I go through a
>uninserted media step. A progress for me then before I did the same with
>the following result:
>
>Scenario same as above EXCEPT I mount via mount <mountpoint> (/mnt/Aopto).
>My entry in fstab: /dev/sdc /mnt/Aopto ext2 noauto 0 0
>
>Now I mounted the device via mount <mountpoint>
>Ok, behaves ok.
>Now umounting the drive and ejecting it.
>Mount an empty drive (no cartridge in) with mount /dev/sdc <mountpoint>
>gives a few errors, ok.
>Umount the empty drive.
>gives a few errors, same as above, ok.
>Mount an empty drive with mount /dev/sdc <mountpoint>
>gives a few more errors.
>but different than above in first scenario.
>
>unmount /mnt/Aopto
>umount: /mnt/Aopto/: not mounted
>
>Now I change the side of the cartridge and do the same again.
>Doing so I get the WRONG content listed from Bside. The tree is still
>the same as on the Aside.
>
>And here it stops. The only chance to get the Bside was a reboot with
>Bside inserted at boottime.
>
>Now I can save this step :-)
>
>My question: why this behavior when working with fstab entries???
>
>A detailed log of the procedures I did is available..
>
>Thanks for any hint
>Andreas
>
>
>Please read the FAQ at http://www.tux.org/lkml/
>
>------------------------------
>
>From: Andrea Arcangeli <and...@suse.de>
>Date: Thu, 16 Sep 1999 14:01:52 +0200 (CEST)
>Subject: [patch] __flush_one_page() on i386
>
>On i386 we are doing a flush_tlb_current_task() when a __flush_one_page()
>is requested. This is plain wrong as if there isn't the `invlpg` asm
>instruction we should revert to the only bit more larger (and CPU local)
>operation by moving back and forth the %%cr3 register so doing a full
>flush of the local tlb and nothing more.
>
>This bug is on both 2.2.x and 2.3.x.
>
>In 2.3.18 __flush_one_page() actually is called by flush_tlb_page() in
>smp.c and flush_tlb_page is called by kswapd. kswapd has no current->mm so
>then flush_tlb_current_page() oopses because current->mm is null and it's
>trying to dereference it to flush the mm of the current (kswapd) task.
>
>Fix against 2.3.18ac4:
>
>- --- 2.3.18ac4-tlb/include/asm-i386/pgtable.h.~1~ Wed Sep 15 14:48:32 1999
>+++ 2.3.18ac4-tlb/include/asm-i386/pgtable.h Wed Sep 15 15:47:41 1999
>@@ -44,7 +44,7 @@
> do { unsigned long tmpreg; __asm__ __volatile__("movl %%cr3,%0\n\tmovl
%0,%%cr3":"=r" (tmpreg) : :"memory"); } while (0)
>
> #ifndef CONFIG_X86_INVLPG
>- -#define __flush_tlb_one(addr) flush_tlb()
>+#define __flush_tlb_one(addr) __flush_tlb()
> #else
> #define __flush_tlb_one(addr) \
> __asm__ __volatile__("invlpg %0": :"m" (*(char *) addr))
>
>Andrea
>
>
>Please read the FAQ at http://www.tux.org/lkml/
>
>------------------------------
>
>From: Alan Cox <al...@lxorguk.ukuu.org.uk>
>Date: Thu, 16 Sep 1999 13:10:17 +0100 (BST)
>Subject: Re: [patch] __flush_one_page() on i386
>
>> In 2.3.18 __flush_one_page() actually is called by flush_tlb_page() in
>> smp.c and flush_tlb_page is called by kswapd. kswapd has no current->mm
so
>> then flush_tlb_current_page() oopses because current->mm is null and it's
>> trying to dereference it to flush the mm of the current (kswapd) task.
>
>For this latter item would it not be better to give kswapd and everything
else
>a valid mm (eg the task 0 mm), just to be more regular
>
>
>
>Alan
>
>
>Please read the FAQ at http://www.tux.org/lkml/
>
>------------------------------
>
>From: Brian Geisel <bri...@microlite.com>
>Date: Thu, 16 Sep 1999 08:46:40 -0400
>Subject: Symbios DAC960 and Quad Xeon
>
>Greetings,
> I'm having trouble with a system booting with an Intel SC450NX
>motherboard. The board has Quad Xeon 450Mhz with a built-in Symbios 53C896
>dual SCSI3 Ultra2 and a Symbios 5353C810AE Narrow Fast SCSI controller. It
>is also using the 0-Channel Mylex AcceleRAID 200 card.
>
> The System boots fine normally. The Symbios is built into the kernel and
>I believe the DAC960 is as well (I believe because I can't actually get my
>hands on the system - That's the catch to the whole thing). The problem
>occurs when they use boot disks. I work for Microlite Corporation and we
>make a boot/recovery solution that builds custom boot disks. Now we're
>booting with LILO (just like they normally do) and have checked their
>lilo.conf file for any special command line parameters. There are none.
>We're also using the same kernel they use to boot with, and have grabbed
>any loadable modules they may have installed.
> When the system starts to boot it gets to the NCR/Symbios. It then finds
>three drives on that card (which I'm told it doesn't do from the HD, they
>appear instead as a RAID drive on the AcceleRAID). This is in the midst of
>several error messages, all of which come from an assert line in the NCR
>driver (line 7780 - while it's looking up the ccb in ncr_int_sir).
> This problem doesn't occur when booting from the HD which is what is
>really confusing me.
>
> Ok, so here's the information I'm really looking for:
>
>Should this be using the sym53c8xx driver instead of the ncr53c8xx driver?
>What might be the differences there, or what they should be used for?
>
>Is there any chance this is modified by the SMP stuff? My first thought is
>no, but I have heard stuff floating around about problems with LILO booting
>Symbios cards on SMP systems. (Something about it taking part of the 640k
>that LILO expects is unused).
>
>Anything I should know about the boot process between these two cards?
>Should the NCR/Symbios find the drives and then the DAC960 'take' them, or
>should this have already happened in hardware? Does one need to be loaded
>before the other? Anything else that might be special under this
>configuration, parameters, etc?
>
>TIA,
>
>Brian Geisel
>
>Please read the FAQ at http://www.tux.org/lkml/
>
>------------------------------
>
>From: "Richard B. Johnson" <ro...@chaos.analogic.com>
>Date: Thu, 16 Sep 1999 09:06:04 -0400 (EDT)
>Subject: Re: ext2 file sizes
>
>On Thu, 16 Sep 1999, Clem Taylor wrote:
>
>> "Richard B. Johnson" wrote:
>> > On Wed, 15 Sep 1999, Blankenship, Keith wrote:
>> > > I am having some difficulty with the ext2 file systems. I need to
generate a
>> > > file that will be > 5 Gigabytes, and there appears to be a file size
cap at
>> > > approximately 2 Gig. I am running what appears to be a version 2.0.36
>> > > Kernel. Is there anything I can adjust, or do to increase the maximum
file
>> > > size? Or is there a newer kernel that may work?
>> >
>> > Note that on a 32-bit machine, toff_t, used as fpos_t, for file
offsets,
>> > i.e., lseek, is unsigned 32 bits. You will not be able to access such a
>> > file on a 32-bit machine. There has been some work on changing this
>> > to 'long long' (__kernel_loff_t, in ../asm/posix_types.h although you
may
>> > need a new 'C' runtime library to take advantage of this.
>> >
>> > What on earth are you doing with a single _file_ of that size? If you
>> > need a gob of storage for data acquisition, you might be better off
>> > with a dedicated raw device. Since you access it in blocks, rather than
>> > bytes, you won't have a size limitation for a few more years.
>>
>> I work with compressed video and my average file size is 3-6 gigs,
>> increasing
>> all the time (higher bitrates). A while back I looked into using Linux
for
>> a
>> video application and gave up and went with Solaris and Irix because of
>> the lack
>> of large file support. I was hoping that 2.4 would have large file
support
>> (and
>> not just on 64 bit platforms), but that isn't looking promising based on
>> comments here. Going to a 64 bit off_t (on 32 bit platforms) is a major
>> change
>> and will have a serious impact in user space. Just look at all the pain
>> Solaris
>> and Irix had in making the move.
>>
>> --Clem
>>
>
>Here, we acquire great gobs of data (CAT Scan Data), typically 4 gb per
>run. I run it off to a dedicated SCSI. After it's converted into useful
>images, the images are saved in a conventional database on a file-system.
>
>This seems to be a real good approach because, even with smaller files
>the ext2 file-system has a problem keeping up with the data-rate when
>buffers get filled and must be flushed to disk. Our data rate is
>2880*1440 = 4,147,200 longwords/second. We throw away the high byte
>so we have a sustained data rate of 12,441,600 bytes/second. Good SCSI
>controllers (BusLogic) keep up with this fine. The ext2 file-system keeps
>up with this until its buffers get full. Then it's too bad.
>
>Writes to a dedicated SCSI solved all our problems. I can sustain writes
>at these speeds forever (until the drive is full).
>
>
>Cheers,
>Dick Johnson
> **** FILE SYSTEM WAS MODIFIED ****
>Penguin : Linux version 2.2.4 on an i686 machine (400.59 BogoMips).
>Warning : It's hard to remain at the trailing edge of technology.
>
>
>Please read the FAQ at http://www.tux.org/lkml/
>
>------------------------------
>
>From: ebi4 <eb...@ozob.net>
>Date: Thu, 16 Sep 1999 08:08:02 -0500 (CDT)
>Subject: Re: State of USB drivers
>
>> "Popular" (my definition of it :) devices work well. By that, I mean
>> things like keyboards, mice, hubs. Audio devices are being worked on, as
>> are cameras. UPSs and other power devices are being worked on. Ethernet
>> adapters are on the list, and we're getting some support. Parallel and
>> serial converters are nonstandard, proprietary, and not supported.
>>
>> Did I miss anything?
>
>Scanners, if not part of the last group.
>
>::::: Gene Imes http://www.ozob.net :::::
>
>
>Please read the FAQ at http://www.tux.org/lkml/
>
>------------------------------
>
>From: Mark Buda <her...@clark.net>
>Date: 16 Sep 1999 09:12:03 -0400
>Subject: Re: 2.2.12: serial driver swapping characters?
>
>>>>>> "Dag" == Dag Brattli <da...@cs.uit.no> writes:
>
> Dag> The Doctor What <doc...@gerf.org> writes:
> >> I have similar problems with my palm. I use pyrite, but the
> >> symtoms are the same (wierd packet error, and then everything
> >> else bombs).
>
> Dag> I'm experiencing the same problem with 2.2.12, but I'm using
> Dag> IrCOMM which emulates serial port communication over IrDA
> Dag> (infrared).
>
>My problem appears to be solved (so far). I removed my Megahertz
>EM1144-T PCMCIA Ethernet/modem card and inserted a D-Link DFE-650 Fast
>Ethernet PC Card, and the problem seems to go away.
>
>I imagine it has something to do with the serial_cs driver. I'm using
>version 3.0.12 of PCMCIA Card Services.
>- --
>I get my monkeys for nothing and my chimps for free.
>http://www.clark.net/pub/hermit/
>
>Please read the FAQ at http://www.tux.org/lkml/
>
>------------------------------
>
>From: Jacek Kopecky <kope...@inf.upol.cz>
>Date: Thu, 16 Sep 1999 15:15:17 +0200 (MET DST)
>Subject: [PATCH] console alertness - notifying of console activities
>
>Hello.
>
>I always wanted the console to be able to alert me when something happened
it
>it. So I started writing a patch to allow me to set a virtual console so
that
>it gets switched to whenever it beeps. I then expanded it so that now you
>can:
> - have the vc switched to when it beeps,
> - have the vc switched to when anything is written to it,
> - have the vc beep whenever anything is written to it
> - do nothing of the above. 8-)
>
>See the documentation file at the end of the patch for details. And tell me
>if you feel such functionality is desired.
>
>The patch applies cleanly with 2.2.12 and 2.3.18, it was originally made
for
>2.2.10.
>
>(Is this mail enough for the patch to get into the main kernel or what
should
>I do if I get positive responses about it?)
>
> Jacek Kopecky
>
>E-mail: jacek.kopecky(at)upol.cz (ISO Latin 2 encoding gladly accepted)
>WWW: http://www.inf.upol.cz/~kopeckyj ICQ: 49514837
>Finger kope...@alpha.inf.upol.cz for Geek Code.
>
>The patch:
>- ----------------------------------------------------------
>
>diff -u --recursive linux-2.2.12/drivers/char/console.c
linux/drivers/char/console.c
>- --- linux-2.2.12/drivers/char/console.c Thu Mar 11 01:51:35 1999
>+++ linux/drivers/char/console.c Thu Jul 15 11:55:38 1999
>@@ -66,6 +66,8 @@
> *
> * Resurrected character buffers in videoram plus lots of other trickery
> * by Martin Mares <m...@atrey.karlin.mff.cuni.cz>, July 1998
>+ *
>+ * Console alertness by Jacek Kopecky <ja...@unforgettable.com>, July 1999
> */
>
> #include <linux/module.h>
>@@ -1263,6 +1265,10 @@
> case 14: /* set vesa powerdown interval */
> vesa_off_interval = ((par[1] < 60) ? par[1] : 60) * 60 * HZ;
> break;
>+ case 15: /* set console alertness:
>+ 1 beep on write, 2 switch on beep , 3 switch on write*/
>+ alert = (par[1] > 2) ? 3 : par[1];
>+ break;
> }
> }
>
>@@ -1402,6 +1408,8 @@
> save_cur(currcons);
> if (do_clear)
> csi_J(currcons,2);
>+
>+ alert = 0;
> }
>
> static void do_con_trol(struct tty_struct *tty, unsigned int currcons, int
c)
>@@ -1416,6 +1424,9 @@
> case 7:
> if (bell_duration)
> kd_mksound(bell_pitch, bell_duration);
>+ /* switch console if alertness on beep */
>+ if ((alert == 2) && (currcons != fg_console))
>+ change_console(currcons);
> return;
> case 8:
> bs(currcons);
>@@ -1927,6 +1938,16 @@
> }
> FLUSH
> enable_bh(CONSOLE_BH);
>+
>+ /* Switch to this console if alertness is 3
>+ * or beep if alertness is 1
>+ */
>+ if (alert && (currcons != fg_console)) {
>+ if (alert == 3) change_console(currcons);
>+ else if ((alert == 1) && bell_duration)
>+ kd_mksound(bell_pitch, bell_duration);
>+ }
>+
> return n;
> #undef FLUSH
> }
>diff -u --recursive linux-2.2.12/drivers/char/console_macros.h
linux/drivers/char/console_macros.h
>- --- linux-2.2.12/drivers/char/console_macros.h Thu Sep 17 18:35:03 1998
>+++ linux/drivers/char/console_macros.h Wed Jun 30 20:50:00 1999
>@@ -64,6 +64,7 @@
> #define complement_mask (vc_cons[currcons].d->vc_complement_mask)
> #define s_complement_mask (vc_cons[currcons].d->vc_s_complement_mask)
> #define hi_font_mask (vc_cons[currcons].d->vc_hi_font_mask)
>+#define alert (vc_cons[currcons].d->vc_alert)
>
> #define vcmode (vt_cons[currcons]->vc_mode)
>
>diff -u --recursive linux-2.2.12/include/linux/console_struct.h
linux/include/linux/console_struct.h
>- --- linux-2.2.12/include/linux/console_struct.h Thu Sep 17 18:35:04 1998
>+++ linux/include/linux/console_struct.h Wed Jun 30 22:45:11 1999
>@@ -65,6 +65,7 @@
> unsigned int vc_can_do_color : 1;
> unsigned int vc_report_mouse : 2;
> unsigned int vc_kmalloced : 1;
>+ unsigned int vc_alert : 2; /* Switch to this console on write or beep
*/
> unsigned char vc_utf : 1; /* Unicode UTF-8 encoding */
> unsigned char vc_utf_count;
> int vc_utf_char;
>diff -u --recursive --new-file linux-2.2.12/Documentation/console-alertness
linux/Documentation/console-alertness
>- --- linux-2.2.12/Documentation/console-alertness Thu Jan 1 01:00:00 1970
>+++ linux/Documentation/console-alertness Fri Aug 6 22:45:45 1999
>@@ -0,0 +1,31 @@
>+This file describes the console alertness function of linux virtual
consoles
>+as implemented by Jacek Kopecky (ja...@unforgettable.com) in July 1999.
>+
>+First, what does console alertness mean anyway?
>+In cases when you want to be warned when something changes or only beeps
on a
>+virtual console other than the one that's active at the moment (so that
you
>+don't see the changes yourself), you can use the following escape
sequences
>+to set the console-alertness-level to get some warnings:
>+
>+echo -ne "\033[15;0]" > /dev/ttyX alertnes off ("beep on beep")
>+echo -ne "\033[15;1]" > /dev/ttyX beep on write to the console
>+echo -ne "\033[15;2]" > /dev/ttyX switch to the console on beep
>+echo -ne "\033[15;3]" > /dev/ttyX switch to the console on write
>+
>+At the level 1 the virtual console /dev/ttyX beeps whenever anything is
>+written to it but only if the console is not currently the foreground
console.
>+The level 2 makes the console get switched to whenever it beeps. On the
highest
>+level the console gets switched to on each write to it.
>+
>+A side-effect of setting beep-on-write (1) or switch-on-write (3) on
another
>+console is that the other console beeps or is switched to, this comes
handy
>+as a test it's working. 8-)
>+The sequence for setting the switch-on-beep (2) level can be enhanced to
give
>+the same kind of test:
>+
>+echo -ne "\033[15;2]\a" > /dev/ttyX
>+
>+The setting sequences may seem to be a little too user-unfriendly so I'm
>+planning to try to incorporate alertness setting into the setterm package.
>+
>+Enjoy. 8-)
>
>
>Please read the FAQ at http://www.tux.org/lkml/
>
>------------------------------
>
>From: af...@jhu.edu
>Date: Thu, 16 Sep 1999 09:31:24 -0400 (EDT)
>Subject: Email subject line
>
>Hi, Guys:
>
> I am a new comer to this email list and presumably I should shut up for
>a while. But this is really a traffic email-list and I got about 100
>emails everyday, which stuffed my mailbox and made it very hard for me
>to read other kinds of emails--emails from friends, department activities,
>etc.
>
> I have a little suggestion as to the email subject line being sent out
>by the email list server program. Can we add something like [LK] in front
>of every email subject line? LK stands for Linux Kernel. I was in several
>other email list before which has high traffic too. They did something
>like this and it was very neat.
>
> This amount of traffic almost scared the hell out of me and it
>surely stoped some people from joining us. So hope my suggestions can be
>adopted.
>
>with regards to all your hard working developers,
>Fei
>
>
>Please read the FAQ at http://www.tux.org/lkml/
>
>------------------------------
>
>From: Daniel...@t-online.de
>Date: Thu, 16 Sep 1999 15:34:57 +0200 (CEST)
>Subject: Re: Mouse input corrupted under X 3.3.3.1 with kernel 2.2.12
>
>On 15 Sep, Alec Smith wrote:
>
>> Any pointers would be greatly appreciated. I can try to provide more
>> information as needed.
>
> This is a know problem.... You have to use X 3.3.5...
>
>Servus,
> Daniel
>
>
>Please read the FAQ at http://www.tux.org/lkml/
>
>------------------------------
>
>From: "Stephen D. Williams" <s...@lig.net>
>Date: Thu, 16 Sep 1999 09:50:44 -0400
>Subject: > 15K simultaneous connections EXAMPLE program/OS config needed,
was: Re: POSIX aio vs completion ports
>
>Stephen, or anyone else, are you aware of a test program that illustrates
the
>use of existing (2.2.12+) mechanisms to efficiently handle many sockets?
>
>I have several needs for this, including a communication concentrator
server.
>I could use a collection of processes each having at most 1024 (or
something
>similarly small) sockets each working together, but although this appears
to
>be workable it sounds like there are much more efficient ways.
>
>What will slow down at the OS level with many sockets?
>
>Is there a limit to the number of connections per IP address, assuming many
>different client IP's? (In other words, is there any problem with running
out
>of local sockets? There shouldn't be really since a client program that
>doesn't specify a certain local socket doesn't care if it has that same
socket
>number used with N different remote IP's.)
>
>I really want to handle 100,000 TCP connections simultaneously per system,
>eventually.
>
>I can see that there are two ways to optimize: for many descriptors with
>little traffic and fewer (but still large) descriptors with a lot of
traffic.
>Ideally, if there were a significant latency or performance benefit, you
>should be able to dynamically tune the handling of a connection.
>
>Thanks
>sdw
>
>"Stephen C. Tweedie" wrote:
>
>> Hi,
>>
>> On Sat, 11 Sep 1999 21:26:47 -0700, John Gardiner Myers
>> <jgm...@netscape.com> said:
>>
>> > Alan Cox wrote:
>> >> POSIX real time signal queues are effectively completion ports.
>>
>> > You must not have understood the post you were replying to. POSIX real
>> > time signal queues are inferior to completion ports in many ways.
>>
>> > * As far as I know, there is no way to allocate a POSIX real time
signal
>> > number in a thread safe manner. There is no equivalent to the socket()
>> > system call--one must just pick a number and hope that no other thread
>> > in the same process just picked the same number.
>>
>> As far as I know, completion ports still have the demultiplexing done in
>> a single place, so in that model you still have to have extra explicit
>> application/library cooperation to let libraries share queues.
>>
>> > * Chuck Lever informs me that the signal queue might overflow, leading
>> > to lost completion notifications. There is no reasonable way for an
>> > application to recover from such a condition.
>>
>> There is. The existing kernel supports sending a separate, higher
>> priority event to notify the application of overflow, and poll is a
>> sufficient recovery mechanism. You don't expect overflow to be a
>> common, performance-critical case.
>>
>> > * POSIX aio lacks a mechanism to request read polls.
>>
>> Who is talking about POSIX aio? That is a totally different API. For
>> the purposes in question --- networking IO --- leave POSIX aio well
>> alone, Unix O_NONBLOCK plus completion events is a perfectly adequate
>> API. The async IO API is not necessary or desirable.
>>
>> > * POSIX aio lacks asynchronous versions of writev() and sendfile().
>> > (Though the lack of an aio_writev() is made less important by
>> > TCP_CORK.)
>>
>> See the previous point: you'd be crazy to want aio_writev on a socket.
>>
>> --Stephen
>>
>> -
>> To unsubscribe from this list: send the line "unsubscribe linux-kernel"
in
>> the body of a message to majo...@vger.rutgers.edu
>> Please read the FAQ at http://www.tux.org/lkml/
>
>- --
>OptimaLogic - Finding Optimal Solutions
Web/Crypto/OO/Unix/Comm/Video/DBMS
>
>s...@lig.net Stephen D. Williams Senior Consultant/Architect
http://sdw.st
>
>43392 Wayside Cir,Ashburn,VA 20147-4622 703-724-0118W 703-995-0407Fax
5Jan1999
>
>
>
>
>Please read the FAQ at http://www.tux.org/lkml/
>
>------------------------------
>
>From: Andrea Arcangeli <and...@suse.de>
>Date: Thu, 16 Sep 1999 15:47:06 +0200 (CEST)
>Subject: Re: [patch] __flush_one_page() on i386
>
>On Thu, 16 Sep 1999, Alan Cox wrote:
>
>>> In 2.3.18 __flush_one_page() actually is called by flush_tlb_page() in
>>> smp.c and flush_tlb_page is called by kswapd. kswapd has no current->mm
so
>>> then flush_tlb_current_page() oopses because current->mm is null and
it's
>>> trying to dereference it to flush the mm of the current (kswapd) task.
>>
>>For this latter item would it not be better to give kswapd and everything
else
>>a valid mm (eg the task 0 mm), just to be more regular
>
>AFIK Linus removed such &init_mm thing because tsk->mm == 0 is more
>regular in his opinion.
>
>The tsk->mm == 0 thing Oopses because the i386 version of
>__flush_one_page() is buggy (and my patch fixes the bug). With the bug
>fixed the new tsk->mm == 0 logic (should) work fine on i386 too without
>further changes. And just to avoid mistakes: with "i386" this time I mean
>a real 386 and not a 486 or Pentium with the invlpg instruction ;).
>
>As last thing tsk->mm == 0 is faster as the asm doesn't need to play with
>the &init_mm address (the zero version will work with a plain testl on the
>tsk->mm value).
>
>Andrea
>
>
>Please read the FAQ at http://www.tux.org/lkml/
>
>------------------------------
>
>From: Ben Collins <bcol...@debian.org>
>Date: Thu, 16 Sep 1999 05:50:41 -0400
>Subject: Re: Email subject line
>
>On Thu, Sep 16, 1999 at 09:31:24AM -0400, af...@jhu.edu wrote:
>> Hi, Guys:
>>
>> I am a new comer to this email list and presumably I should shut up for
>> a while. But this is really a traffic email-list and I got about 100
>> emails everyday, which stuffed my mailbox and made it very hard for me
>> to read other kinds of emails--emails from friends, department
activities,
>> etc.
>>
>> I have a little suggestion as to the email subject line being sent out
>> by the email list server program. Can we add something like [LK] in front
>> of every email subject line? LK stands for Linux Kernel. I was in several
>> other email list before which has high traffic too. They did something
>> like this and it was very neat.
>>
>> This amount of traffic almost scared the hell out of me and it
>> surely stoped some people from joining us. So hope my suggestions can be
>> adopted.
>>
>> with regards to all your hard working developers,
>> Fei
>
>It would probably be easier for you to use some sort of filtering (procmail
>works nice, and Netscape/Outlook on windows has the ability aswell).
>
>I'm sub'd to over 20 mailing lists, and get about 2k emails a day...even
with
>a subject line, I couldn't do it without procmail filtering.
>
>Ben
>
>Please read the FAQ at http://www.tux.org/lkml/
>
>------------------------------
>
>From: Coy A Hile <hi...@cse.psu.edu>
>Date: Thu, 16 Sep 1999 09:51:55 -0400 (EDT)
>Subject: Re: Email subject line
>
>af...@jhu.edu sez....
>>
>>
>> I have a little suggestion as to the email subject line being sent out
>> by the email list server program. Can we add something like [LK] in front
>> of every email subject line? LK stands for Linux Kernel. I was in several
>> other email list before which has high traffic too. They did something
>> like this and it was very neat.
>>
>An even better solution would be to have majordomo do that for us.
>
>Coy
>
>- --
>Coy Hile
>hi...@cse.psu.edu
>"Theirs not to reason why; theirs but to do...."
>Tennyson, "Charge of the Light Brigade"
>
>Please read the FAQ at http://www.tux.org/lkml/
>
>------------------------------
>
>From: Jesse Pollard <pol...@tomcat.admin.navo.hpc.mil>
>Date: Thu, 16 Sep 1999 08:52:51 -0500 (CDT)
>Subject: Re: Resource Limits Architecture
>
>> From: Jordan Mendelson <jo...@wserv.com>
>>
>> A few days ago I mentioned that robust resource limits really didn't
exist in
>> Linux. Alan Cox (who I thought moved to the US, but uses a UK email
address)
>> mentioned
>>
>> ftp://ftp.nc.orc.ru/pub/Linux/people/saw/kernel/userbean.5
>>
>> which appears to be a good start for resource limits, however I still
don't
>> find it robust enough.
>>
>> I have searched high and low and can't find a good complete resource
limits
>> architecture in any Unix implementation. As I see it, there should be a
few
>> different categories of limits:
>>
>> Per-System : Limits which are placed on all processes
>> Per-Group : Limits which are placed on all processes from a group id
>> Per-User : Limits which are placed on all processes from a user id
>> Per-Process Group : Limits which are placed on a group of processes
(shared)
>> Per-Process : Limits which are placed on a process
>> Per-Thread Group : Limits which are placed on a group of threads (shared)
>> Per-Thread : Limits which are placed on a thread
>>
>> Now of course, these will overlap since a thread is part of a process
which
>> has a user id a group id and runs on a system. The accepted semantics of
the
>> most generalized type being the upper limit of the more specific type
should
>> work fine, so:
>>
>> Per-Thread's hard limit is Per-Thread-Group
>> Per-Thread-Group's hard limit is Per-Process
>> Per-Process's hard limit is Per-Process-Group
>> Per-Process-Group's hard limit is Per-User
>> Per-User's hard limit is Per-Group (if mult groups, lowest would be hard
>> limit)
>> Per-Group's hard limit would be Per-System
>> Per-System's hard limit would be the kernel's upper limit
>>
>> The commercial unices I've seen really only do per-user, per-process,
>> per-thread and per-system which is probably adequate most of the time.
>>
>> A lot of resources themselves overlap as well. So the hard limit of
network
>> buffers would be total memory.
>>
>> There are of course some resource limits which I'd love to see
implemented:
>>
>> Wall clock time - Time in seconds the process has physically ran, current
time
>> - start time. As far as I know, the only time related resource limit is
CPU
>> time which only measures time in the run state.
>>
>> Number of CPUs - Processes/Threads will be restricted to use a maximum of
x
>> cpus. This would be a great thing for a per-group limit, you could set
users
>> in group 'cpuhogs' to a maximum of 2 CPUs and the rest of the system to 4
>> CPUs.
>>
>> Disk Space - Sure would be nice if this was all handled by a single
interface.
>> Right now we have a separate quota interface, I'm not sure how feasible
it is
>> to have disk space limits settable by the same interface as other things.
>>
>> Is this a bit of an overkill?
>>
>> Are there any unices or other OS's which implement these types of
resource
>> limits?
>
>yes - look at Cray UNICOS. Besides resource limits there are also security
>limits (MLS), fair-share limits (fading away now), project (project level
>accounting) limits, a different set for batch and interactive
(resource/project
>limits). There is also an utility to generate/collate accounting records
>into an extended accounting record for job level accounting.
>
>Note: I want project level accounting separate from group access control.
>The place I work has several projects that share group access to a given
set
>of files that is owned (and quota limited) to only one project. Files may
>be created by all project members, with group access - but accounting for
>each file/process is done to the specific project the user belongs to.
>
>Now that Linux is reaching into the "supercomputer" range with beowuf
>clusters, it is becoming more important to track (and justify) the usage
>on large systems. If my site (a DoD shared resource center) were ever to
>consider a cluser then we will have to be able to track (and report on)
>this stuff.
>
>- -------------------------------------------------------------------------
>Jesse I Pollard, II
>Email: pol...@navo.hpc.mil
>
>Any opinions expressed are solely my own.
>
>Please read the FAQ at http://www.tux.org/lkml/
>
>------------------------------
>
>From: Martin Mares <m...@atrey.karlin.mff.cuni.cz>
>Date: Thu, 16 Sep 1999 15:55:16 +0200
>Subject: Re: Email subject line
>
>Hello,
>
>> I am a new comer to this email list and presumably I should shut up for
>> a while. But this is really a traffic email-list and I got about 100
>> emails everyday, which stuffed my mailbox and made it very hard for me
>> to read other kinds of emails--emails from friends, department
activities,
>> etc.
>>
>> I have a little suggestion as to the email subject line being sent out
>> by the email list server program. Can we add something like [LK] in front
>> of every email subject line? LK stands for Linux Kernel. I was in several
>> other email list before which has high traffic too. They did something
>> like this and it was very neat.
>>
>> This amount of traffic almost scared the hell out of me and it
>> surely stoped some people from joining us. So hope my suggestions can be
>> adopted.
>
> Why not set up procmail filtering based on the `Sender' header instead?
>My .procmailrc contains:
>
>:0
>*Sender: owner-linux-kernel@
>Mail/kernel_list
>
> Have a nice fortnight
>- --
>Martin `MJ' Mares <m...@ucw.cz> http://atrey.karlin.mff.cuni.cz/~mj/
>Faculty of Math and Physics, Charles University, Prague, Czech Rep., Earth
>"Everything counts in large amounts." -- Depeche Mode
>
>Please read the FAQ at http://www.tux.org/lkml/
>
>------------------------------
>
>From: rob...@scot-mur.demon.co.uk
>Date: Mon, 13 Sep 1999 23:16:01 +0100
>Subject: oops when insmodding msp3400, bttv 0.6.4, linux 2.2.12
>
>[sorry if you receive this twice, I didn't sea it on either list the first
>time.]
>
>Hi
>
>I got the below oops when loading the msp3400 module from bttv 0.6.4. It
>also happened with the bttv included with the kernel, but I didn't write
>that one down.(user space hung, kernel still responded to pings etc.) It
>is reproducible.
>
>this is a dual pii 450, (overclocked to 504, but its been *very* stable
>for months now).
>128 mb of ram.
>sb 128 soundcard (es1370) alsa driver loaded.
>Hauppage wintv (don't know the model number, it has an ir controller, no
>radio). Here is the lspci output:
>
>00:00.0 Host bridge: Intel Corporation 440BX/ZX - 82443BX/ZX Host bridge
(rev 03)
>00:01.0 PCI bridge: Intel Corporation 440BX/ZX - 82443BX/ZX AGP bridge (rev
03)
>00:07.0 ISA bridge: Intel Corporation 82371AB PIIX4 ISA (rev 02)
>00:07.1 IDE interface: Intel Corporation 82371AB PIIX4 IDE (rev 01)
>00:07.2 USB Controller: Intel Corporation 82371AB PIIX4 USB (rev 01)
>00:07.3 Bridge: Intel Corporation 82371AB PIIX4 ACPI (rev 02)
>00:0b.0 SCSI storage controller: Adaptec AIC-7880U
>00:11.0 Multimedia audio controller: Ensoniq ES1370 [AudioPCI] (rev 01)
>00:12.0 VGA compatible controller: Cirrus Logic GD 5430/40 [Alpine] (rev
22)
>00:13.0 Multimedia video controller: Brooktree Corporation Bt878 (rev 02)
>00:13.1 Multimedia controller: Brooktree Corporation Bt878 (rev 02)
>
>oops follows:
>
>i2c: driver registered: msp3400
>Unable to handle kernel NULL pointer dereference at virtual address
00000001
>current->tss.cr3 = 0700e000, %cr3 = 0700e000
>*pde = 00000000
>oops: 0000
>cpu: 1
>eip: 0010:[<00000001>]
>eflags: 00010283
>eax: 00000001 ebx: c8898b68 ecx: 0006df9a edx: 0006df9a
>esi: 00000000 edi: c63c2424 ebp: c63c23c0 esp: c778de18
>ds: 0018 es: 0018 ss: 0018
>Process insmod (pid: 617, process nr: 60, stackpage=c778d000)
>stack: 00000000 c021f600 c01a4611 c8898b68 00000000 00000001 c01a4611
000008cc
> 00000000 00000001 c88b7070 c8898b68 c8898b68 00000019 00000282
c33abb40
> c33abb40 c8898b68 00000000 0000a7bc 00000000 00000000 c88b8d4a
c8898b68
>Call Trace: [<c01a4611>] [<c8898b68>] [<c01a4611>] [<c88b7070>]
[<c8898b68>] [<c8898b68>] [<c8898b68>]
> [<c88b8d4a>] [<c8898b68>] [<c888f6fa>] [<c8898b68>] [<c8898b68]>
[<c888f170>] [<c011654a>] [<c88ba420>]
> [<c888fe60>] [<c88b7048>] [<c888f541>] [<c8898b68<] [<c88ba420>]
[<c88b7000>] [<c88b7050>] [<c88b7000>]
> [<c88b7050>] [<c88b944c>] [<c88ba420>] [<c88b7050>] [<c88b7048>]
[<c01186f3>] [<c88b7000>] [<c8c00000>]
> [<c88b3000>] [<c88b7048>] [<c01093c1>] [<c01092bc>] [<c88b7000>]
>Code: <1>Unable to handle kernel NULL pointer dereference at virtual
address 00000001
>current->tss.cr3 = 0700e000, %cr3 = 0700e000
>*pde = 00000000
>
>
>
>
>and the ksymoops output:
>
>ksymoops 0.7c on i686 2.2.12. Options used
> -V (default)
> -k /proc/ksyms (default)
> -L (specified)
> -o /lib/modules/2.2.12/ (default)
> -m /boot/System.map-2.2.12 (default)
>
>Unable to handle kernel NULL pointer dereference at virtual address
00000001
>current->tss.cr3 = 0700e000, %cr3 = 0700e000
>*pde = 00000000
>oops: 0000
>cpu: 1
>eip: 0010:[<00000001>]
>Using defaults from ksymoops -t elf32-i386 -a i386
>eflags: 00010283
>eax: 00000001 ebx: c8898b68 ecx: 0006df9a edx: 0006df9a
>esi: 00000000 edi: c63c2424 ebp: c63c23c0 esp: c778de18
>ds: 0018 es: 0018 ss: 0018
>Process insmod (pid: 617, process nr: 60, stackpage=c778d000)
>stack: 00000000 c021f600 c01a4611 c8898b68 00000000 00000001 c01a4611
000008cc
> 00000000 00000001 c88b7070 c8898b68 c8898b68 00000019 00000282
c33abb40
> c33abb40 c8898b68 00000000 0000a7bc 00000000 00000000 c88b8d4a
c8898b68
>Call Trace: [<c01a4611>] [<c8898b68>] [<c01a4611>] [<c88b7070>]
[<c8898b68>] [<c8898b68>] [<c8898b68>]
> [<c88b8d4a>] [<c8898b68>] [<c888f6fa>] [<c8898b68>] [<c8898b68]>
[<c888f170>] [<c011654a>] [<c88ba420>]
> [<c888fe60>] [<c88b7048>] [<c888f541>] [<c8898b68<] [<c88ba420>]
[<c88b7000>] [<c88b7050>] [<c88b7000>]
> [<c88b7050>] [<c88b944c>] [<c88ba420>] [<c88b7050>] [<c88b7048>]
[<c01186f3>] [<c88b7000>] [<c8c00000>]
> [<c88b3000>] [<c88b7048>] [<c01093c1>] [<c01092bc>] [<c88b7000>]
>Code: <1>Unable to handle kernel NULL pointer dereference at virtual
address 00000001
>Warning (Oops_code): trailing garbage ignored on Code: line
> Text: 'Code: <1>Unable to handle kernel NULL pointer dereference at
virtual address 00000001'
> Garbage: 'Unable to handle kernel NULL pointer dereference at virtual
address 00000001'
>Warning (Oops_code_values): Code looks like message, not hex digits. No
disassembly attempted.
>
>>>EIP; 00000001 Before first symbol <=====
>Trace; c01a4611 <__const_udelay+29/30>
>Trace; c8898b68 <END_OF_CODE+45ee4/????>
>Trace; c01a4611 <__const_udelay+29/30>
>Trace; c88b7070 <END_OF_CODE+643ec/????>
>Trace; c8898b68 <END_OF_CODE+45ee4/????>
>Trace; c8898b68 <END_OF_CODE+45ee4/????>
>Trace; c8898b68 <END_OF_CODE+45ee4/????>
>Trace; c88b8d4a <END_OF_CODE+660c6/????>
>Trace; c8898b68 <END_OF_CODE+45ee4/????>
>Trace; c888f6fa <END_OF_CODE+3ca76/????>
>Trace; c8898b68 <END_OF_CODE+45ee4/????>
>Trace; c888fe60 <END_OF_CODE+3d1dc/????>
>Trace; c88b7048 <END_OF_CODE+643c4/????>
>Trace; c888f541 <END_OF_CODE+3c8bd/????>
>Trace; c88b7050 <END_OF_CODE+643cc/????>
>Trace; c88b944c <END_OF_CODE+667c8/????>
>Trace; c88ba420 <END_OF_CODE+6779c/????>
>Trace; c88b7050 <END_OF_CODE+643cc/????>
>Trace; c88b7048 <END_OF_CODE+643c4/????>
>Trace; c01186f3 <sys_init_module+467/4e8>
>Trace; c88b7000 <END_OF_CODE+6437c/????>
>Trace; c8c00000 <END_OF_CODE+3ad37c/????>
>Trace; c88b3000 <END_OF_CODE+6037c/????>
>Trace; c88b7048 <END_OF_CODE+643c4/????>
>Trace; c01093c1 <error_code+2d/34>
>Trace; c01092bc <system_call+34/38>
>Trace; c88b7000 <END_OF_CODE+6437c/????>
>
>current->tss.cr3 = 0700e000, %cr3 = 0700e000
>*pde = 00000000
>
>2 warnings issued. Results may not be reliable.
>
>What does all that end of code stuff mean? Is it not finding the module
>symbols?
>
>Regards
>
> --
>Rob Murray
>
>Please read the FAQ at http://www.tux.org/lkml/
>
>------------------------------
>
>From: Frank van Maarseveen <f...@tasking.nl>
>Date: Thu, 16 Sep 1999 16:22:10 +0200
>Subject: 2.2.18ac5 NFS client bug
>
>Try the following:
>
> sleep 10000 >file & // client
> rm file;date >file // server
> ls -l file // client again
> ls: file: Stale NFS file handle
>
>mount options: rw,nodev,rsize=8192,wsize=8192,acregmin=0
>
>I also tried:
> linux-2.2.6-ac3: ok
> linux-2.2.10-ac11 bug (a bit worse)
>
>btw: uname -r says 2.3.18ac4 instead of 2.3.18ac5
>
>- --
>Frank
>
>Please read the FAQ at http://www.tux.org/lkml/
>
>------------------------------
>
>From: Anil Kumar S R <ani...@sasi.com>
>Date: Thu, 16 Sep 1999 19:56:23 +0530
>Subject: Problem in inserting module
>
>Hi,
> 1. After I compile the driver , If I insert the module I am getting
> following warning:
>
> ./cardtest.o: kernel-module version mismatch
> ./cardtest.o was compiled for kernel version 2.2.5-15
> while this kernel is version 2.2.5-22.
>
> cardtest is name of module to be inserted.
> what needs to be done to this?
>
> 2. After inserting the module should I have it in /proc/modules.
> b'coz /proc/modules has modules which are loaded and the usage
> count of the module can be looked from /proc/modules.
> so when I insert a module(cardtest) should I get it in /proc/modules?
>
>
>Please read the FAQ at http://www.tux.org/lkml/
>
>------------------------------
>
>From: "Maciej W. Rozycki" <ma...@ds2.pg.gda.pl>
>Date: Thu, 16 Sep 1999 16:28:44 +0200 (MET DST)
>Subject: Re: Lockups - lost interrupt
>
>On Sun, 12 Sep 1999 mi...@chiara.csoma.elte.hu wrote:
>
>> FYI, i'm working on a patch for 2.3 that adds the NMI oopser (optionally,
>> because 1) it doesnt work on all SMP boxes, and 2) it forces the timer
irq
>> to the BP) to the 2.3 kernel. Looks like one of the most common uses of
>> IKD is lockup detection - the rest is mostly used by kernel hackers. I'll
>> post it together with some other x86 APIC fixes and irq cleanups soon.
>
> Why wouldn't the NMI oopser work on a given SMP system? And why the
>timer has to be delivered to the BP if these NMIs are exploited? I don't
>see any reasons but I might be missing something.
>
> Note that even if IRQ0 is not connected to any I/O APIC, the LINT0 line
>is usually broadcasted and even if it's not, NMI may be distributed by the
>catcher using "all excluding self" IPI. It is theoretically possible that
>there exist i82489DX based systems that have the NMI output of local APICs
>not connected to the NMI input of CPUs, but have you ever seen or heard of
>such a brain-damaged system? It wouldn't be MPS-compliant, anyway.
>
> I might add a modified NMI oopser to my pending APIC patches (I should
>make them available tomorrow, BTW -- they are almost ready but I need to
>perform some additional tests), if you don't object, that would handle all
>legal cases of timer configuration. The current implementation included
>in the ikd patch is somewhat simplistic, indeed.
>
> I don't object the oopser to be optional, of course.
>
>- --
>+ Maciej W. Rozycki, Technical University of Gdansk, Poland +
>+--------------------------------------------------------------+
>+ e-mail: ma...@ds2.pg.gda.pl, PGP key available +
>
>
>
>Please read the FAQ at http://www.tux.org/lkml/
>
>------------------------------
>
>End of linux-kernel-digest V1 #4467
>***********************************
>
>To subscribe to linux-kernel-digest, send the command:
>
> subscribe linux-kernel-digest
>
>in the body of a message to "Majo...@vger.rutgers.edu". If you want
>to subscribe something other than the account the mail is coming from,
>such as a local redistribution list, then append that address to the
>"subscribe" command; for example, to subscribe "local-linux-kernel":
>
> subscribe linux-kernel-digest local-lin...@your.domain.net
>
>A non-digest (direct mail) version of this list is also available; to
>subscribe to that instead, replace all instances of "linux-kernel-digest"
>in the commands above with "linux-kernel".
>
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majo...@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/
Miquel van Smoorenburg
Was it really nessecary to quota a 2000-line digest _just_ to
post this one line message ?
ftp://ftp.linux.org.uk/pub/linux/sct/fs/jfs/
Mike.
--
... somehow I have a feeling the hurting hasn't even begun yet
-- Bill, "The Terrible Thunderlizards"
Theodore Y. Ts'o
Date: Thu, 16 Sep 1999 13:35:44 -0400
Any news on ext3 filesystem?? Where can I get info?
There is a 0.01 release which came out 1-2 weeks ago. It was against
2.2.2, and has bugs which have since been fixed. I imagine that Stephen
will be releasing a new version fairly shortly.
So the good news is that most of the code has been written but we still
need to do some bugfixing (and bug finding) before it will be completely
production ready.
- Ted
Alex Buell
> There is a 0.01 release which came out 1-2 weeks ago. It was against
> 2.2.2, and has bugs which have since been fixed. I imagine that
> Stephen will be releasing a new version fairly shortly.
Just out of interest, will there be tools to convert from ext2 to ext3?
Cheers,
Alex
--
Legalise cannabis today!
http://www.tahallah.demon.co.uk - updated!
David Weinehall
> From: "Alex" <al...@numerix.com>
> Date: Thu, 16 Sep 1999 13:35:44 -0400
>
> Any news on ext3 filesystem?? Where can I get info?
>
> There is a 0.01 release which came out 1-2 weeks ago. It was against
> 2.2.2, and has bugs which have since been fixed. I imagine that Stephen
> will be releasing a new version fairly shortly.
Where can I find that alpha, and where do you put upcoming alphas/betas?
> So the good news is that most of the code has been written but we still
> need to do some bugfixing (and bug finding) before it will be completely
> production ready.
Well, I don't care if it's production-quality or not, I just want to
try... I have an empty 80MB SCSI-drive to test on, so no real damage can
be done...
/David
_ _
// David Weinehall <t...@acc.umu.se> /> Northern lights wander \\
// Project MCA Linux hacker // Dance across the winter sky //
\> http://www.acc.umu.se/~tao/ </ Full colour fire </
-
Chuck Campbell
> On Thu, 16 Sep 1999, Theodore Y. Ts'o wrote:
>
> > There is a 0.01 release which came out 1-2 weeks ago. It was against
> > 2.2.2, and has bugs which have since been fixed. I imagine that
> > Stephen will be releasing a new version fairly shortly.
>
cp?, tar?, dump/restore?
I'd really rather see someone qualified work on finishing a stable journalled
file system, and spend my own time converting with anything that will work.
-chuck
--
ACCEL Services, Inc.| Specialists in Gravity, Magnetics | 1(713)993-0671 ph.
1980 Post Oak Blvd. | and Integrated Interpretation | 1(713)960-1157 fax
Suite 2050 | |
Houston, TX, 77056 | Chuck Campbell | camp...@neosoft.com
| President & Senior Geoscientist |
"Integration means more than having all the maps at the same scale!"
Jesse Pollard
> From: Chuck Campbell <camp...@neosoft.com>
> On Thu, Sep 16, 1999 at 08:32:40PM +0100, Alex Buell wrote:
> > On Thu, 16 Sep 1999, Theodore Y. Ts'o wrote:
> >
> > > There is a 0.01 release which came out 1-2 weeks ago. It was against
> > > 2.2.2, and has bugs which have since been fixed. I imagine that
> > > Stephen will be releasing a new version fairly shortly.
> >
> > Just out of interest, will there be tools to convert from ext2 to ext3?
>
> cp?, tar?, dump/restore?
>
> I'd really rather see someone qualified work on finishing a stable journalled
> file system, and spend my own time converting with anything that will work.
Check the readme in ftp://ftp.linux.org.uk/pub/linux/sct/fs/jfs/README
for complete details and disclaimers.
Setting up a ext3 is straightforward. partial extraction:
...
Now, you want to make a journaled filesystem (recommended) or journal an
existing one (for the exceptionally stupid/brave). Great. Go right
ahead, make a new ext2 filesystem if you need to, and mount the
filesystem you want to journal.
Be aware that the jfs patch does _not_ change the ext2 code. Rather, it
makes a copy of ext2 called ext3, and all the fancy footwork takes place
in that. You don't have to run ext3 on all your valuable filesystems:
just use it on the throwaway ones.
Now, create a journal file. I don't know how big it should be yet: the
rules of thumb have yet to be established! However, try (say) 2MB for a
small filesystem on a 486; maybe up to 30MB on a bit 18G 10krpm
Cheetah. Or whatever you want. You'll need to make sure that the file
is preallocated, so use something like:
dd if=/dev/zero of=/mnt/sparefs/journal.dat bs=1k count=10000
assuming you want a 10MB journal on a 1k ext2 filesystem mounted on
/mnt/sparefs. You need to find the journal inode's inode number, too:
ls -i /mnt/sparefs/journal.dat
For a newly created filesystem, this will probably show
12 journal.dat
OK, 12 is the expected number for a clean fs.
Now, umount as ext2. Take a deep breath. Now mount as ext3, giving it
the inode number of the file to be mounted as a journal:
mount -t ext3 /dev/sdb2 /mnt/sparefs -o journal=12
Bingo. That's it. Enjoy!
...
-------------------------------------------------------------------------
Jesse I Pollard, II
Email: pol...@navo.hpc.mil
Any opinions expressed are solely my own.
-
Theodore Y. Ts'o
From: Alex Buell <alex....@tahallah.demon.co.uk>
> There is a 0.01 release which came out 1-2 weeks ago. It was against
> 2.2.2, and has bugs which have since been fixed. I imagine that
> Stephen will be releasing a new version fairly shortly.
Just out of interest, will there be tools to convert from ext2 to ext3?
No real tools are needed; it's just a matter of mount -t ext3 with an
appropriate mount option to ask it to create the journal inode. After
you unmount an ext3 volume with journaling, you'll be able to mount it
using ext2.
Some future extensions (like B-tree directories) change this in the
future, but if you're only using journalling, it's completely backwards
compatible.
- Ted
H. Peter Anvin
By author: Chuck Campbell <camp...@neosoft.com>
In newsgroup: linux.dev.kernel
> >
> > Just out of interest, will there be tools to convert from ext2 to ext3?
>
>
> I'd really rather see someone qualified work on finishing a stable journalled
> file system, and spend my own time converting with anything that will work.
>
Yes, we need ext3 more than we need an ext2->ext3 converter, but on
the other hand, perhaps someone else can work on the ext3 converter.
-hpa
--
<h...@transmeta.com> at work, <h...@zytor.com> in private!
Theodore Y. Ts'o
From: David Weinehall <t...@acc.umu.se>
Where can I find that alpha, and where do you put upcoming
alphas/betas?
ftp://ftp.uk.linux.org/pub/linux/sct/fs/jfs/
Note that the 0.0.1 release has a number of caveats; it only works on
Linux 2.2.2, and if used as your root filesystem, it will turn /dev into
a socket. :-)
Well, I don't care if it's production-quality or not, I just want to
try... I have an empty 80MB SCSI-drive to test on, so no real damage can
be done...
That's about the right place to test things right now... you may want
to wish for Stephen's next version, which will fix a number of bugs and
will port things to 2.2.12.
- Ted
Michael Bacarella
> > There is a 0.01 release which came out 1-2 weeks ago. It was against
> > 2.2.2, and has bugs which have since been fixed. I imagine that
> > Stephen will be releasing a new version fairly shortly.
>
cp :)
--Michael Bacarella
Ph. Marek
>> > 2.2.2, and has bugs which have since been fixed. I imagine that
>> > Stephen will be releasing a new version fairly shortly.
>>
>> Just out of interest, will there be tools to convert from ext2 to ext3?
>
>cp :)
and how about LVM? is it anywhere in 2.3 (or 2.2)???
Stephen C. Tweedie
On Thu, 16 Sep 1999 21:31:20 +0200 (MET_DST), David Weinehall
<t...@acc.umu.se> said:
>> There is a 0.01 release which came out 1-2 weeks ago. It was against
>> 2.2.2, and has bugs which have since been fixed. I imagine that Stephen
>> will be releasing a new version fairly shortly.
> Where can I find that alpha, and where do you put upcoming alphas/betas?
ftp://ftp.uk.linux.org/pub/linux/sct/fs/jfs
--Stephen
Stephen C. Tweedie
On Thu, 16 Sep 1999 15:18:44 -0400, "Theodore Y. Ts'o" <ty...@mit.edu>
said:
> There is a 0.01 release which came out 1-2 weeks ago. It was against
> 2.2.2, and has bugs which have since been fixed. I imagine that Stephen
> will be releasing a new version fairly shortly.
0.0.2 over the weekend is the plan. I've fixed all of the known bugs
except for one, but that one requires a bit of a reworking of how I
track committed buffers which are still needed by the transaction code.
Once that is done I expect to have a version which is pretty stable
against the 2.2.2 kernel. I already have a 2.2.12 version of the 0.0.1
code done so merging the 2.2.2 fixes into the 2.2.12 stream should not
be hard.
> So the good news is that most of the code has been written but we still
> need to do some bugfixing (and bug finding) before it will be completely
> production ready.
Currently the released journaling code journals everything, including
data. That is deliberate: journaling metadata only turns out to be
_lots_ more complex (hint---what happens if you delete a block of
metadata and reallocate it as data or vice-versa), so although all of
the necessary support is there in the journaling layers, the released
ext3 code does not do metadata-only journaling yet.
Once people have had a chance to thrash out any bugs left in the 0.0.2
code, I'll enable the metadata-only journaling and we can all watch the
pretty fireworks as filesystems all over the planet explode in a curious
and interesting manner...
Stephen C. Tweedie
On Fri, 17 Sep 1999 08:08:42 +0200, "Ph. Marek" <ma...@bmlv.gv.at> said:
>>> Just out of interest, will there be tools to convert from ext2 to ext3?
> is it possible to resize it? while mounted, possibly?
There are tools being developed for LVM to resize a mounted filesystem.
Stephen C. Tweedie
On Thu, 16 Sep 1999 20:32:40 +0100 (BST), Alex Buell
<alex....@tahallah.demon.co.uk> said:
> Just out of interest, will there be tools to convert from ext2 to ext3?
That isn't finalised. I _might_ make the ext3 journal use a reserved
inode, but right now there isn't actually a difference between ext2 and
ext3. You just create a journal file on the ext2 filesystem and tell
the kernel where to find it. Then when you mount it as ext3, everything
is automatically journaled to that file.
If you uncleanly shutdown, then the ext3 filesystem will have a
compatibility flag set in the superblock to prevent you from remounting
it as ext2 without doing a recovery step first. Once that is done, it
becomes mountable as ext2 again.
Stefan Monnier
> There are tools being developed for LVM to resize a mounted filesystem.
This is becoming irrelevant since "we'll see once we get there", but here
it goes anyway: how about resizing the log file ?
Stefan
Dave
the near future? Or is ext3 destined to be simply ext2 + jfs?
Michael Bacarella
> While we're on the topic of ext3, is there any chance of seeing ACLs in
> the near future? Or is ext3 destined to be simply ext2 + jfs?
Could you clarify this for me? What does adding ACLs mean?
I always thought that permission bits and file owner/group fell under
the category of "access control lists".
--Michael Bacarella
Andreas Dilger
> is it possible to resize it? while mounted, possibly?
I have written a kernel patch + user space tools which allows mounted
resizing of ext2 filesystems. I had a quick look at the ext3 code, and
there aren't many changes to the super.c file which would affect my
resizer, so they shouldn't have any problem trying to coexist. The patches
themselves won't apply cleanly together, since they both add a new variable
to the parse_options() function. There are likely a few other conflicts in
the patch as well. You can get my patch from my web page:
http://www-mddsp.enel.ucalgary.ca/People/adilger/online-ext2/
As for LVM, it is entirely independent of filesystems. There is already
a fairly widely used Linux LVM at:
http://linux.msede.com/lvm
Cheers, Andreas
--
Andreas Dilger University of Calgary \ "If a man ate a pound of pasta and
Micronet Research Group \ a pound of antipasto, would they
Dept of Electrical & Computer Engineering \ cancel out, leaving him still
http://www-mddsp.enel.ucalgary.ca/People/adilger/ hungry?" -- Dogbert
Dave
On Sat, 18 Sep 1999, Michael Bacarella wrote:
>
> Could you clarify this for me? What does adding ACLs mean?
>
> I always thought that permission bits and file owner/group fell under
> the category of "access control lists".
>
What I meant by ACL was the way NTFS handles it (and afaik solaris has it
now) : You can assign much more fine grained access to the file. Instead
of just one group and one owner, you can give any user or group of users
any set of permissions. Meaning multiple groups and multiple "individual"
access rights. Its not too difficult to envision doing this with
backwards compatability to rwxrwxrwx. Its something I would really like
to see Linux get in the near future whether ext3 or otherwise.
Benjamin Scott
>> the near future? Or is ext3 destined to be simply ext2 + jfs?
>
> I always thought that permission bits and file owner/group fell under
> the category of "access control lists".
Short answer: ACLs can be arbitrarily complex, and are defined by the user.
You can implement a lot of ACL functionality (but not all) in terms of Unix
users and groups, but to do so, you need to modify the system user and group
lists. ACLs are built in terms of existing security IDs. Example: Allow
just Fred to read a file in your home directory.
ACLs can grant rights to multiple security IDs. Example: Grant the
documentation folks read access to the source code directory, but the
programmers read+write.
ACLs can exclude security IDs as well as including them. Example: Grant all
members of accounting access to the payroll database, except for Bob.
ACLs can make another user a trustee (owner equivalence) of a resource.
Example: You are going on vacation for two weeks, so you allow Sam to modify
the security permissions of your project directory, in case someone else needs
access.
ACLs can generally be inherited by subdirectories and files. Example: You
can grant all programmers full rights to a shared source code directory. You
can do most of this with UNIX and the SGID bit, but files are still owned by
the creator, meaning other programmers cannot modify permissions (e.g., toggle
read-only or execute status).
There are probably other things that I am forgetting, but you get the idea.
Hope this helps! :-)
--
Benjamin Scott
drago...@iname.com
Bear Giles
>
> now) : You can assign much more fine grained access to the file. Instead
> of just one group and one owner, you can give any user or group of users
> any set of permissions.
ACLs can (and should?) provide additional restrictions. Each entry
should specify
user and/or group
permissions
RWX at a minimum. On some systems you can specify "append-only",
"creation" (sys_link and sys_symlink), "deletion" (sys_unlink and
sys_truncate) and "modify attributes" (sys_chown, sys_chgrp, sys_chacl).
EXT2FS already supports two of these flags (au). A trusted file
system should also always perform secure deletions (s).
nature of access
Limit access to specific times of the day or days of the week.
Limit access to specific ports (e.g., only console/virtual terminals)
On some systems you can also bracket the access with "valid" and
"expiry" dates. This allows you to specify that the file can only
be accessed between 8AM and 5 PM on weekdays, and from
01 November to 15 December 1999.
ACLs are a "discretionary access control," the specs also appear to
require a similar "non-discretionary access control" which applies to
everyone and which *can't* be set by the owner of the file. The
concept seems similar to the mount options "readonly" and "noexec"
taken down to the level of files.
If you think this is more than NTFS supports, I agree. I don't know
if it got a waiver or if the ISO document is more restrictive.
This sounds like a lot of information, but I think it depends on
your perspective. If you're trying to shove it all into an
existing inode structure you'll have problems. If you're willing
to use a single disk block, possibly one shared with other files
(by this I mean a full disk block which acts as an exemplar, not
each file having exclusive access to part of a disk block) then
you can pack in a *lot* of security information.
BTW, other information that could be (or needs to be) included is:
- auditing flags (e.g., record all access, of any kind, of /etc/shadow)
- sensitivity level ("B1" classification, it's a bitmap indicating
unclassified/sensitive/confidential/secret/top secret &
compartmentalization)
- encryption information
There are at least two types of encryption information. One is the
actual encryption key, itself encrypted by a super-block level
encryption key specified during "mount." Another type of encryption
info is something like the cryptographic hash of the unencrypted
first block of the file. The user must pass the password, via an
IOCTL, which decrypts the first block so it produces the known
hash value, before the user can use read() and write().
(Ref: Sept. _SysAdmin_ magazine, and the recently adopted IS 15408
discussed in the editoral at the beginning of the magazine).
Bear Giles
bgi...@coyotesong.com
Mike A. Harris
>Any news on ext3 filesystem?? Where can I get info?
>
>Thanks.
>
2 things:
1) Why did you write a NEW message to the mailing list by
choosing REPLY? Was typing in:
"To: linux-...@vger.rutgers.edu"
on a NEW message too difficult? Don't know how to use cut and
paste?
2) Why on earth did you QUOTE an ENTIRE MESSAGE DIGEST that is
75k+?
Complete and total incompetance. Please, get a clue.
>Alex
>-----Original Message-----
>From: owner-linux-...@vger.rutgers.edu
><owner-linux-...@vger.rutgers.edu>
>To: linux-ker...@vger.rutgers.edu
><linux-ker...@vger.rutgers.edu>
>Date: Thursday, September 16, 1999 10:49 AM
>Subject: linux-kernel-digest V1 #4467
>
>
[SNIP 75k message digest]
--
Mike A. Harris Linux advocate
Computer Consultant GNU advocate
Capslock Consulting Open Source advocate
[insert witty random tagline or cool URL here]
Rik van Riel
> On Thu, 16 Sep 1999, Alex wrote:
>
> >Any news on ext3 filesystem?? Where can I get info?
> >
> >Thanks.
> >
>
> 2 things:
Now come on Mike, don't get pedantic over nettiquette issues.
It would be much more productive if we'd all sent a personal
reply (75 kB) to Alex with the answer in it. Then he would
probably get it just fine...
Rik
--
The Internet is not a network of computers. It is a network
of people. That is its real strength.
--
work at: http://www.reseau.nl/
home at: http://www.nl.linux.org/~riel/
Mike A. Harris
>> >Any news on ext3 filesystem?? Where can I get info?
>> >
>> >Thanks.
>> >
>>
>> 2 things:
>
>Now come on Mike, don't get pedantic over nettiquette issues.
>
>It would be much more productive if we'd all sent a personal
>reply (75 kB) to Alex with the answer in it. Then he would
>probably get it just fine...
Heheh. True. Unfortunately, that would likely result in a
further reply coming back at over 200k or more...
Since this IS l-k, maybe we should attach the latest linux kernel
to such messages... ;o)
--
Mike A. Harris Linux advocate
Computer Consultant GNU advocate
Capslock Consulting Open Source advocate
[insert witty random tagline or cool URL here]
Stephen C. Tweedie
On 17 Sep 1999 15:18:17 -0400, "Stefan Monnier"
<monnier+lists/linux/kernel/news/@tequila.cs.yale.edu> said:
>>>>>> "Stephen" == Stephen C Tweedie <s...@redhat.com> writes:
>> There are tools being developed for LVM to resize a mounted filesystem.
> This is becoming irrelevant since "we'll see once we get there", but here
> it goes anyway: how about resizing the log file ?
Easy, but not online.
--Stephen
Stephen C. Tweedie
On Fri, 17 Sep 1999 18:26:27 -0400 (EDT), Dave <da...@istream.net> said:
> While we're on the topic of ext3, is there any chance of seeing ACLs in
> the near future?
http://aerobee.informatik.uni-bremen.de/acl_eng.html
Jeff Haumont
as these do for ext2? It'd be great to have one set of common commands to
learn for working with ACLs ...
"Stephen C. Tweedie" wrote:
Jeff Haumont (hau...@acm.org)
Jesse Pollard
From: Jeff Haumont <hau...@acm.org>
>Anyone know if the coda project intends to make their ACLs work the same way
>as these do for ext2? It'd be great to have one set of common commands to
>learn for working with ACLs ...
>
>"Stephen C. Tweedie" wrote:
>
>> Hi,
>>
>> On Fri, 17 Sep 1999 18:26:27 -0400 (EDT), Dave <da...@istream.net> said:
>>
>> > While we're on the topic of ext3, is there any chance of seeing ACLs in
>> > the near future?
I'd be much happier if the ACL interface moved into the VFS layer, and up
to individual file systems to support/not support ACL's. This way the
implementation would become isolated from the kernel support, allowing a
common set of user utilities, and user/OS interface.
random thoghts on, don't take too seriously:
The VFS interface shouldn't need much over a "get_next_ACL" call, providing
the inode number and ACL index.
-------------------------------------------------------------------------
Jesse I Pollard, II
Email: pol...@navo.hpc.mil
Any opinions expressed are solely my own.
-
Theodore Y. Ts'o
From: Jesse Pollard <pol...@tomcat.admin.navo.hpc.mil>
>Anyone know if the coda project intends to make their ACLs work the same way
>as these do for ext2? It'd be great to have one set of common commands to
>learn for working with ACLs ...
I'd be much happier if the ACL interface moved into the VFS layer, and up
to individual file systems to support/not support ACL's. This way the
implementation would become isolated from the kernel support, allowing a
common set of user utilities, and user/OS interface.
The problem is that different, already established filesystems: AFS,
Coda, NTFS, etc., all have different ACL semantics. For example, AFS
only has an ACL on a per-directory basis. I'm not sure about Coda, but
it may be the same as AFS. NTFS uses 128 bit UUID's in its ACL's to
name users and groups. The POSIX acl interface uses uid_t and gid_t for
user and group id's.
So it would be *nice* to do this, but there's quite a lot of design work
to make the interfaces similar enough that a single interface could be
used at both the UI and system call level. I won't say that it's
impossible, but it's definitely non-trivial.
- Ted
Jesse Pollard
> From ty...@ATHENA.MIT.EDU Mon Sep 20 14:54:48 1999
> From: Jesse Pollard <pol...@tomcat.admin.navo.hpc.mil>
>
> >Anyone know if the coda project intends to make their ACLs work the same way
> >as these do for ext2? It'd be great to have one set of common commands to
> >learn for working with ACLs ...
>
> I'd be much happier if the ACL interface moved into the VFS layer, and up
> to individual file systems to support/not support ACL's. This way the
> implementation would become isolated from the kernel support, allowing a
> common set of user utilities, and user/OS interface.
>
> The problem is that different, already established filesystems: AFS,
> Coda, NTFS, etc., all have different ACL semantics. For example, AFS
> only has an ACL on a per-directory basis. I'm not sure about Coda, but
> it may be the same as AFS. NTFS uses 128 bit UUID's in its ACL's to
> name users and groups. The POSIX acl interface uses uid_t and gid_t for
> user and group id's.
I thought AFS was ACLs were implemented similarly to the DFS - ACLs emulated
in an authentication server... I didn't know that Coada even had ACLS, only
a network sync technique for disconnected operation (prevents a lot of
authentication capability... the user walks off taking the files, then hacks
at them). The translation of UUID's would almost have to be done via a table
lookup, but hopefully done in the filesystem layer (unless Linux is the
server).
> So it would be *nice* to do this, but there's quite a lot of design work
> to make the interfaces similar enough that a single interface could be
> used at both the UI and system call level. I won't say that it's
> impossible, but it's definitely non-trivial.
Sounds like a graduate project someplace, huh :)
I've been looking for ACLs (and MLS ...) but until real recently hadn't
seen anything that was sufficently production level (well beta at least).
I'm also watching the freeswan (IPsec) and RSBAC projects for a possible
MLS based PC system for consolidated console system (console handling for
multiple hosts, combined timestamped console log, positive authentication
for remote connections, labeling of audit data and log files...). It could
also be used for archiving audit analysis and be a security analysis system.
I'm using a Linux IA pc for that now, but minus much of the audit logs and
security tracing. Works fine for now (2 Origin 2000, 1 Origin 200, 1 Onyx2,
and 4 Cray systems).
Combining all of this (misc security projects) into one server system for
Kerberos authentication would also make a very difficult system to hack.
-------------------------------------------------------------------------
Jesse I Pollard, II
Email: pol...@navo.hpc.mil
Any opinions expressed are solely my own.
-
Oliver Xymoron
> The problem is that different, already established filesystems: AFS,
> Coda, NTFS, etc., all have different ACL semantics. For example, AFS
> only has an ACL on a per-directory basis. I'm not sure about Coda, but
> it may be the same as AFS. NTFS uses 128 bit UUID's in its ACL's to
> name users and groups. The POSIX acl interface uses uid_t and gid_t for
> user and group id's.
>
> So it would be *nice* to do this, but there's quite a lot of design work
> to make the interfaces similar enough that a single interface could be
> used at both the UI and system call level. I won't say that it's
> impossible, but it's definitely non-trivial.
Not to mention that auditing a system using ACLs for security is much*
more difficult. And that such a system would break all mature UNIX
tools' notions of what is secure. ACLs tend to be an answer for people who
are asking the wrong question anyway.
--
"Love the dolphins," she advised him. "Write by W.A.S.T.E.."
Steve Dodd
> Not to mention that auditing a system using ACLs for security is much*
> more difficult. And that such a system would break all mature UNIX
> tools' notions of what is secure. ACLs tend to be an answer for people who
> are asking the wrong question anyway.
Perhaps, but the existing system isn't flexible enough. Normal users need to
be able to define their own group(s) and add / remove other users from it.
That's a userspace thang though, not a kernel problem.
--
"House Plants are for ornamental use only and not for consumption"
Notice in Sainsbury's Supermarket, London - Daily Mail
Steve Dodd
> at them). The translation of UUID's would almost have to be done via a table
> lookup, but hopefully done in the filesystem layer (unless Linux is the
> server).
For NTFS, I'd always envisaged pluggable kernel modules to do the translation,
which would allow a number of solutions, across a range of complexity. The fs
would certainly want to cache the mappings, and the modules would probably
want some way to invalidate bits of the cache. This would allow a really
simple solution for someone who just wants to access his NT volumes on his
home PC - a module that read a list of mappings from a file and kept them
in memory, or maybe the list could be populated by writing to a device or
files in /proc. Really complicated solutions could talk to a userspace
daemon (with precautions taken to avoid deadlocks), or implement some sort
of network protocol.
--
"I don't have any solution but I certainly admire the problem."
- Ashleigh Brilliant
Benjamin Scott
> Not to mention that auditing a system using ACLs for security is much*
> more difficult. And that such a system would break all mature UNIX
> tools' notions of what is secure. ACLs tend to be an answer for people who
> are asking the wrong question anyway.
I strongly disagree with that last sentence. There are a number of things
that ACLs let you do, that standard UNIX security does not. I would even
argue that ACLs can lead to better security, as it allows you to specify
combinations which would be difficult or impossible with traditional UNIX
mechanisms. Like most anything, it depends on the application.
I agree that, like any powerful tool, ACLs can be easily misused. But that
theory applies to UNIX in general. :-) I have implemented Linux in
situations as small as a six person company, and even then, ACLs were
something I missed. I would be happy to provide examples if you like.
As far as existing tools and auditing techniques go, yes, ACLs are outside
their domain. However, I believe categorically dismissing all possible
improvements is an error. Otherwise, this mailing list would not exist. :)
--
Benjamin Scott
drago...@iname.com
Helge Hafting
>Coda, NTFS, etc., all have different ACL semantics. For example, AFS
>only has an ACL on a per-directory basis.
Seems to me that some of this can be solved with a good generic
ACL interface in the VFS. Various filesystems may then implement
more or less of the VFS interface depending on what they support.
Just as some filesystems implement links and some don't.
So setting an ACL on something will work if the operation is supported
there. I.e. AFS will reject ACL on a file and NTFS will not. A fs
with extremely ill-fitting semantics may not use all abilities
when used from linux.
Helge Hafting
Jesse Pollard
>On Mon, 20 Sep 1999, Theodore Y. Ts'o wrote:
>> Coda, NTFS, etc., all have different ACL semantics. For example, AFS
>> it may be the same as AFS. NTFS uses 128 bit UUID's in its ACL's to
>> name users and groups. The POSIX acl interface uses uid_t and gid_t for
>> user and group id's.
>>
>> So it would be *nice* to do this, but there's quite a lot of design work
>> to make the interfaces similar enough that a single interface could be
>> used at both the UI and system call level. I won't say that it's
>> impossible, but it's definitely non-trivial.
>
>more difficult. And that such a system would break all mature UNIX
>tools' notions of what is secure. ACLs tend to be an answer for people who
>are asking the wrong question anyway.
How does a user grant crontroled access to a file to a single other user
not in his process group? (or a single user IN the process group, but not
ALL users in the process group?)
Setuid programs are not a safe way to do it since this technique is error
prone, and people do not pay enough attention to the details. Besides it does
not or is not capable of supporting certain file operations in a transparent
manner, the user accessing a file this way must copy it first. Then re-copy
it in case there have been changes... nevermind the possiblility that the
file is a journal/log file that constantly grows.
ACLs are a way a user may choose to grant controled access to file(s) to a
single other user, grant access to a predefined group of users, or deny
access to a user or group of users.
If this is the wrong question, what is the right question?
-------------------------------------------------------------------------
Jesse I Pollard, II
Email: pol...@navo.hpc.mil
Any opinions expressed are solely my own.
-
Jeff Haumont
"Theodore Y. Ts'o" wrote:
> Date: Mon, 20 Sep 1999 11:18:42 -0500 (CDT)
> From: Jesse Pollard <pol...@tomcat.admin.navo.hpc.mil>
>
> >Anyone know if the coda project intends to make their ACLs work the same way
> >as these do for ext2? It'd be great to have one set of common commands to
> >learn for working with ACLs ...
>
> I'd be much happier if the ACL interface moved into the VFS layer, and up
> to individual file systems to support/not support ACL's. This way the
> implementation would become isolated from the kernel support, allowing a
> common set of user utilities, and user/OS interface.
>
> The problem is that different, already established filesystems: AFS,
> Coda, NTFS, etc., all have different ACL semantics. For example, AFS
> only has an ACL on a per-directory basis. I'm not sure about Coda, but
> it may be the same as AFS. NTFS uses 128 bit UUID's in its ACL's to
> name users and groups. The POSIX acl interface uses uid_t and gid_t for
> user and group id's.
>
> So it would be *nice* to do this, but there's quite a lot of design work
> to make the interfaces similar enough that a single interface could be
> used at both the UI and system call level. I won't say that it's
> impossible, but it's definitely non-trivial.
>
The common interface wouldn't have to try to use every feature of the ACLs in the
underlying filesystem. Even a least-common-demoninator interface would be much
better than nothing. Maybe restrict to directory ACLs only, etc.
Another option would be to write some massively intelligent userspace library that
could query the filesystem and divine the correct way to do things. Not something
I'd want to try to debug, verify to be correct and secure, or maintain though ...
Jeff
--
Jeff Haumont <hau...@acm.org>
Casey Schaufler
Helge Hafting Wrote:
> Seems to me that some of this can be solved with a good generic
> ACL interface in the VFS. Various filesystems may then implement
> more or less of the VFS interface depending on what they support.
> Just as some filesystems implement links and some don't.
That works for ACLs, but isn't very satisfactory in general. There
aren't seperate VFS entries for mode bits, uid, and group after all.
If you're going to extend the VFS interface do so to support pairs
of attribute names and data. This way you can support ACLs, Capability
sets, and/or whatever else you can cram into your underlying file
system. Makes optional features easier, too.
Casey Schaufler voice: (650) 933-1634
ca...@sgi.com fax: (650) 933-0170
Stefan Monnier
> Not to mention that auditing a system using ACLs for security is much*
> more difficult. And that such a system would break all mature UNIX
> tools' notions of what is secure. ACLs tend to be an answer for people who
> are asking the wrong question anyway.
No, they simply ask a different question. ACLs should normally not be used
for the part that one might want to audit, but they'll be used for all kinds
of cases where one wants to share some info with some persons.
How can you give read access to some persons, and write access
to some others without ACLs ?
As an ex-AFS user, I must say that it's very convenient to be able to create my
own groups and to setup specific permissions for various groups. I've never
seen a need for such flexibility when setting up system-software, but for
the end user, it's mighty convenient.
Stefan
Jesse Pollard
>The common interface wouldn't have to try to use every feature of the ACLs in the
>underlying filesystem. Even a least-common-demoninator interface would be much
>better than nothing. Maybe restrict to directory ACLs only, etc.
I think the common interface should be something in the middle - support for
ACLs on individual files if possible. If not implemented then return ENOSYS. This
would allow for a suitable generic "not implemented" message to be printed.
There appears to be some support for a VFS modification. It would allow file systems
to be used with no initial alterations. One filesystem could be modified at a time
to support ACLs. This would simplify implementation and debugging of the user access
functions.
>Another option would be to write some massively intelligent userspace library that
>could query the filesystem and divine the correct way to do things. Not something
>I'd want to try to debug, verify to be correct and secure, or maintain though ...
You bet. This would look like another justification for putting it in the
VFS layer anyway. The huge size of the ACL edit function alone - trying to
second-guess the kernel support would be a loosing battle among version numbers
of even one filesystem.
Guess I'll learn more about the VFS layer implementation to see just how
hard it would be...
-------------------------------------------------------------------------
Jesse I Pollard, II
Email: pol...@navo.hpc.mil
Any opinions expressed are solely my own.
-
Jesse Pollard
>Helge Hafting Wrote:
>
>> Seems to me that some of this can be solved with a good generic
>> ACL interface in the VFS. Various filesystems may then implement
>> more or less of the VFS interface depending on what they support.
>> Just as some filesystems implement links and some don't.
>
>That works for ACLs, but isn't very satisfactory in general. There
>aren't seperate VFS entries for mode bits, uid, and group after all.
>If you're going to extend the VFS interface do so to support pairs
>of attribute names and data. This way you can support ACLs, Capability
>sets, and/or whatever else you can cram into your underlying file
>system. Makes optional features easier, too.
That sounds even better - it could even be able to retrieve mandatory
security controls too (as MLS is another thing I would like available).
Theodore Y. Ts'o
From: Jeff Haumont <hau...@acm.org>
The common interface wouldn't have to try to use every feature of the
ACLs in the underlying filesystem. Even a least-common-demoninator
interface would be much better than nothing. Maybe restrict to
directory ACLs only, etc.
The problem is that systems that use per-file ACL's are very different
from systems that use directory ACL's --- apples and oranges. You can't
map one to the other; there is no least common denominator.
- Ted
G.W. Wettstein
} Subject: ACLs (was: Ext3 filesystem info?)
Good afternoon to everyone on the kernel list. I hope that the
approaching mid-week finds things going well.
> On Mon, 20 Sep 1999, Oliver Xymoron wrote:
> > Not to mention that auditing a system using ACLs for security is much*
> > more difficult. And that such a system would break all mature UNIX
> > tools' notions of what is secure. ACLs tend to be an answer for people who
> > are asking the wrong question anyway.
> I strongly disagree with that last sentence. There are a number of things
> that ACLs let you do, that standard UNIX security does not. I would even
> argue that ACLs can lead to better security, as it allows you to specify
> combinations which would be difficult or impossible with traditional UNIX
> mechanisms. Like most anything, it depends on the application.
I would have to agree with the general course that this thread is
taking.
I am in the process of architecting a new service infrastructure for
our local university. It is predicated on a Category of Service model
and as such defines different classes of service as well as QOS type
things for the services.
One of the big issues that I am dealing with right now is file and
print services. We have a reasonably substantial Novell presence and
I am looking at providing file services through a Linux based Samba
solution. I have already integrated our Kerberos/LDAP
authentication/authorization mechanisms into the Samba sources and I
am now looking at issues that will affect a more general roll-out.
One of the things that quickly becomes apparent is that the standard
UNIX permission model becomes a serious limitation when attempting to
replicate Novell file services with an SMB based solution. At least
in a university setting there is a general tendency for groups of
users to want to share files and/or a common workplace. We have
jumped through a number of hoops with groups and somewhat exotic
permission structures to implement desired accessibility models.
I am tracking ACL's under Linux right now to develop a more
generically useful file sharing model with SMB. I think that LDAP
driven ACL support for Samba offers some promise for an intrigueing
set of solutions.
> Benjamin Scott
Greg
}-- End of excerpt from Benjamin Scott
As always,
Dr. G.W. Wettstein Enjellic Systems Development - Specializing
4206 N. 19th Ave. in information infra-structure solutions.
Fargo, ND 58102 WWW: http://www.enjellic.com
Phone: 701-281-1686 EMAIL: gr...@enjellic.com
------------------------------------------------------------------------------
"I am returning this otherwise good typing paper to you because
someone has printed gibberish all over it and put your name at the
top.
-- English Professor, Ohio University
Jesse Pollard
>From: Jeff Haumont <hau...@acm.org>
>
> The common interface wouldn't have to try to use every feature of the
> ACLs in the underlying filesystem. Even a least-common-demoninator
> interface would be much better than nothing. Maybe restrict to
> directory ACLs only, etc.
>
>The problem is that systems that use per-file ACL's are very different
>from systems that use directory ACL's --- apples and oranges. You can't
>map one to the other; there is no least common denominator.
Hmm. How many different classes are there?
POSIX - NTFS (should be), IRIX/Unicos, Solaris, HPUX
Directory only - AFS/DFS, (does the Andrew FS fit here)?
others?
no acls - FAT16/32 ?
How many would have to be supported... How about supporting POSIX, and
possibly one other...?
Granted - one option is emulating ACLs in a file system that doesn't natively
support them is possible. One approach is to allow the FS implementation to
use a "reserved" file to store ACL information. This file might not be
available to users of Linux, but would allow for ACLs. I would not reccommended
it for removable media, since the media could be taken to a non-linux OS and
bypassed. Of course - physical possession of media invalidates the ACLs
anyway.
-------------------------------------------------------------------------
Jesse I Pollard, II
Email: pol...@navo.hpc.mil
Any opinions expressed are solely my own.
-
Stefan Monnier
> That's a userspace thang though, not a kernel problem.
It seems that way, but it's not just a user-space problem because
allowing users to create their own groups and to add people to them
poses problems with the NGROUPS limit, unless you somehow manage to
restrict the interface so that users can only add themselves to groups.
Stefan
Casey Schaufler
G.W. Wettstein wrote:
> I am in the process of architecting a new service infrastructure for
> our local university. It is predicated on a Category of Service model
> and as such defines different classes of service as well as QOS type
> things for the services.
Did you look into rsbac? It's something that I've been mulling over
for it's infrastructure, and I'd welcome the analysis of others.
Casey Schaufler voice: (650) 933-1634
ca...@sgi.com fax: (650) 933-0170
-
Steve Dodd
> > That's a userspace thang though, not a kernel problem.
> It seems that way, but it's not just a user-space problem because
> allowing users to create their own groups and to add people to them
> poses problems with the NGROUPS limit, unless you somehow manage to
> restrict the interface so that users can only add themselves to groups.
So instead of login loading all the groups blindly, have it AND the
list of groups the user is allowed to be in (/etc/group or whatever entries
listing the user) with a list the user has declared she wants to be in,
stored in ~/.group or similar.. Maybe have a su-like program to spawn a shell
with a given list of extra group ids for when you need to do a couple of
things with a particular group list, but don't want to edit your standard
default groups (~/.group).
--
Satellite Safety Tip #14:
If you see a bright streak in the sky coming at you, duck.
Dr. Michael Weller
> On Wed, Sep 22, 1999 at 10:36:54AM -0400, Stefan Monnier wrote:
>
> > > That's a userspace thang though, not a kernel problem.
>
> > It seems that way, but it's not just a user-space problem because
> > allowing users to create their own groups and to add people to them
> > poses problems with the NGROUPS limit, unless you somehow manage to
> > restrict the interface so that users can only add themselves to groups.
>
> So instead of login loading all the groups blindly, have it AND the
> list of groups the user is allowed to be in (/etc/group or whatever entries
> listing the user) with a list the user has declared she wants to be in,
> stored in ~/.group or similar.. Maybe have a su-like program to spawn a shell
This is a pure userspace and login issue. Problems will arise from ftp or
other services authenticating you though, because ftpd would also need to
know as which group member to do file access. It could use ~/.group as
well or use some site specific FTP extension, again a user space issue.
I still won't suggest anyone to do it as it is pretty non standard.
With regards to NGROUPS, I'm sure it can be easily raised. It might be
possible to handle it fully dynamic, but you still want to have a hard
limit to stop a gone mad process to be in a set of almost 2^32 groups.
Also there is a performance issue, any file access will have to loop
through the list of groups to determine if you have access or not, so you
want to keep the list small. If longs lists of group were allowed I'm sure
one can optimize this with a binary search in a sorted list of groups, but
this won't help much in conjunction with ACL's then.
Anyway, I'm pretty sure there is a misunderstanding here. What the
original poster said had nothing to do with a unix group:
> > allowing users to create their own groups and to add people to them
> > poses problems with the NGROUPS limit, unless you somehow manage to
Under no Unix variant I know are users allowed to add/create an own group
where to be in.
However, consider users A and B, A in group GA and B in GB but in no
other common group where user A wants to give access to a file/directory
to user B. Or if they are in a group GC, there are other users there which
must not get access. Also, it is not desirable to make that file/directory
world readable (not to speak of writing).
Now, with acl's, user A can just give access to user B. And even to user C
and D and... . So with acl's, any 'set' of users can define kind of a
virtual group by electing some 'group leader' who creates a file/dir and
gives the other users access to it. NGROUPS or /etc/groups or any root
intervention is not required. There might/will be a limit on the number of
acl rules per file though.
Without acl's you can only do this with the admin creating and managing
the group, and you'll hit the NGROUPS limit when there are many, non
disjunct groups.
So, acls are a nice thing for users which are not admins that want to
share files beyond the rather simplistic group structure of Unix.
Now, the admin might actually not want users to share such info for
whatever reason. So, there are possible security issues. Also, things are
far more complex to review if any user can give access to anyone through
acls. The acls are not seen directly with ls and are seperate on a file
basis, so it is surely a pain to audit, if you want/need to audit it. And
not being able to audit it easily might be a security issue. Like: there
is a suid root executable with unix permissions "rws------" but an acl
allows 'nobody' to exec it (and exploit a bug) but you don't easily notice
it.
Michael.
--
Michael Weller: eow...@exp-math.uni-essen.de, eow...@ms.exp-math.uni-essen.de,
or even mat...@spi.power.uni-essen.de. If you encounter an eowmob account on
any machine in the net, it's very likely it's me.
Jesse Pollard
>On Wed, 22 Sep 1999, Steve Dodd wrote:
>> On Wed, Sep 22, 1999 at 10:36:54AM -0400, Stefan Monnier wrote:
>>
>> > > That's a userspace thang though, not a kernel problem.
>>
>> > It seems that way, but it's not just a user-space problem because
>> > allowing users to create their own groups and to add people to them
>> > poses problems with the NGROUPS limit, unless you somehow manage to
>> > restrict the interface so that users can only add themselves to groups.
>>
>> So instead of login loading all the groups blindly, have it AND the
>> list of groups the user is allowed to be in (/etc/group or whatever entries
>> listing the user) with a list the user has declared she wants to be in,
>> stored in ~/.group or similar.. Maybe have a su-like program to spawn a shell
>
>This is a pure userspace and login issue. Problems will arise from ftp or
>other services authenticating you though, because ftpd would also need to
>know as which group member to do file access. It could use ~/.group as
>well or use some site specific FTP extension, again a user space issue.
>
>I still won't suggest anyone to do it as it is pretty non standard.
>
>With regards to NGROUPS, I'm sure it can be easily raised. It might be
>possible to handle it fully dynamic, but you still want to have a hard
>limit to stop a gone mad process to be in a set of almost 2^32 groups.
>Also there is a performance issue, any file access will have to loop
>through the list of groups to determine if you have access or not, so you
>want to keep the list small. If longs lists of group were allowed I'm sure
>one can optimize this with a binary search in a sorted list of groups, but
>this won't help much in conjunction with ACL's then.
It can't be easily raised. The problem with NFS - the protocol only has
room for 16 entries. As long as communication with non-Linux
systems - fileservers or clients - is done this limit must be respected.
The only way to handle it when the host supports more than 16 is to truncate
the list to 16 when dealing with the remote system. Then you get the problem
of which 16 out of N (where N > 16).
-------------------------------------------------------------------------
Jesse I Pollard, II
Email: pol...@navo.hpc.mil
Any opinions expressed are solely my own.
-
Dr. Michael Weller
> It can't be easily raised. The problem with NFS - the protocol only has
> room for 16 entries. As long as communication with non-Linux
> systems - fileservers or clients - is done this limit must be respected.
> The only way to handle it when the host supports more than 16 is to truncate
> the list to 16 when dealing with the remote system. Then you get the problem
> of which 16 out of N (where N > 16).
Oh, yes! You are right. I completely forgot about NFS. Even worse, old,
classical NFS only supports 8 groups. At some NFS version (or as part of
some vendors defacto standard) it was raised a bit. I remember the NFS
problems we got with several (at that time pretty new) AIX servers where
root appeared to be in more than 8 groups which was a pretty new concept
then.
Michael.
--
Michael Weller: eow...@exp-math.uni-essen.de, eow...@ms.exp-math.uni-essen.de,
or even mat...@spi.power.uni-essen.de. If you encounter an eowmob account on
any machine in the net, it's very likely it's me.
Helge Hafting
[...9]
> So, acls are a nice thing for users which are not admins that want to
> share files beyond the rather simplistic group structure of Unix.
>
> Now, the admin might actually not want users to share such info for
> whatever reason. So, there are possible security issues.
I can't see a security issue. User may do a "chmod oug+rwx filename"
today, giving everybody else full access to their file(s). The ability
to give the same free access to only a subset of everybody don't
seem dangerous to me.
> Also, things are
> far more complex to review if any user can give access to anyone through
> acls. The acls are not seen directly with ls
ls is fixable. Possibly by extending "ls -l" to show acl's or at
least indicate in some way that acl's are present. The latter may
be preferable to avoid script incompatibilities, sonething like this:
Arw-r--r-- 1 helge helge 140 Feb 9 1999 .bash_profile
The 'A' indicates that acl(s) are present, the user may then use
something like "ls --acl" and get the full acl information.
Helge Hafting
Jesse Pollard
> Dr. Michael Well wrote:
> [...9]
> > So, acls are a nice thing for users which are not admins that want to
> > share files beyond the rather simplistic group structure of Unix.
> >
> > Now, the admin might actually not want users to share such info for
> > whatever reason. So, there are possible security issues.
>
> I can't see a security issue. User may do a "chmod oug+rwx filename"
> today, giving everybody else full access to their file(s). The ability
> to give the same free access to only a subset of everybody don't
> seem dangerous to me.
Also: If the administrator doesn't want the users to be able to share then
the administrator needs mandatory access controls. MAC controls would put
the users into separate compartments which would prevent sharing access. But
MAC is still another topic (I'm in favor of it though).
ACLs are descretionary - the user has control over ACL entries, not the
administrator.
> > Also, things are
> > far more complex to review if any user can give access to anyone through
> > acls. The acls are not seen directly with ls
>
> ls is fixable. Possibly by extending "ls -l" to show acl's or at
> least indicate in some way that acl's are present. The latter may
> be preferable to avoid script incompatibilities, sonething like this:
> Arw-r--r-- 1 helge helge 140 Feb 9 1999 .bash_profile
> The 'A' indicates that acl(s) are present, the user may then use
> something like "ls --acl" and get the full acl information.
Due to the possible size of the ACL (it is a list, after all), the UNIX
ls command should not try to implement a "--acl". They could list up
to 256 ACL entries, which would definitely be a pain in a "ls -R --acl".
They only show a flag to indicate an ACL exists. It would be up to the
user to select an appropriate utility to display the ACL for a file/directory.
Consider: ls is used as a search tool to locate certain files that match a
pattern. To exend ls to be able to search an ACL to match a pattern would
be unreasonable; but it is reasonable for a dedicated utility.
-------------------------------------------------------------------------
Jesse I Pollard, II
Email: pol...@navo.hpc.mil
Any opinions expressed are solely my own.
-
Casey Schaufler
> ls is fixable. Possibly by extending "ls -l" to show acl's or at
> least indicate in some way that acl's are present. The latter may
> be preferable to avoid script incompatibilities, sonething like this:
> Arw-r--r-- 1 helge helge 140 Feb 9 1999 .bash_profile
> The 'A' indicates that acl(s) are present, the user may then use
> something like "ls --acl" and get the full acl information.
The much lamented POSIX spec (P1003.2c) used
-rw-r--r--+ 1 helge helge 140 Feb 9 1999 .bash_profile
^ note the plus sign
figuring that most shell scripts wouldn't pay much attention to
that particular position in the output. With the "A" scheme
suggested above you'd have trouble discriminating directories
and files.
POSIX specified a special program to see file ACLs. In Irix we
used "ls -D", because it was available. We rationalized the choice
by saying it stood for Descretionary Access Control. I personally
dislike commands with spelled out options, but then I grew up
using a TeleType, where every keystroke hurt.
--
Casey Schaufler voice: (650) 933-1634
ca...@sgi.com fax: (650) 933-0170
-
Stephen Frost
> Also: If the administrator doesn't want the users to be able to share then
> the administrator needs mandatory access controls. MAC controls would put
> the users into separate compartments which would prevent sharing access. But
> MAC is still another topic (I'm in favor of it though).
>
> ACLs are descretionary - the user has control over ACL entries, not the
> administrator.
Perhaps they could be a 'config' option, so if you really don't want
them you don't have to have them. However, even in a compartmentalized
environment I could see legitimate room for ACLs. If you want things completely
compartmentalized, let everyone operate in a chroot'ed environment where they
have their own sets of passwd files, and filesystems for that matter. In any
case, what it sounds like you're doing really is trying to protect the user
from himself, which is not what I generally consider, and I don't think is
what we really want to go for. When someone deletes a file, it goes away,
forever, it doesn't go into a recycle bin that the user can get it back out
of.
> > > Also, things are
> > > far more complex to review if any user can give access to anyone through
> > > acls. The acls are not seen directly with ls
> >
> > ls is fixable. Possibly by extending "ls -l" to show acl's or at
> > least indicate in some way that acl's are present. The latter may
> > be preferable to avoid script incompatibilities, sonething like this:
> > Arw-r--r-- 1 helge helge 140 Feb 9 1999 .bash_profile
> > The 'A' indicates that acl(s) are present, the user may then use
> > something like "ls --acl" and get the full acl information.
>
> Due to the possible size of the ACL (it is a list, after all), the UNIX
> ls command should not try to implement a "--acl". They could list up
> to 256 ACL entries, which would definitely be a pain in a "ls -R --acl".
> They only show a flag to indicate an ACL exists. It would be up to the
> user to select an appropriate utility to display the ACL for a file/directory.
>
> Consider: ls is used as a search tool to locate certain files that match a
> pattern. To exend ls to be able to search an ACL to match a pattern would
> be unreasonable; but it is reasonable for a dedicated utility.
If you don't want to look for ACLs, don't use --acl... Also, find
is more of what I would call a 'search tool', and would be able to be
modified to handle ACLs. I don't believe it would even be too hard, find
already offers all kinds of things to match against, adding another for
ACLs shouldn't be impossible.
Stephen
Stephen C. Tweedie
On Tue, 21 Sep 1999 12:13:28 +0200, Helge Hafting
<helge....@idb.hist.no> said:
> Seems to me that some of this can be solved with a good generic
> ACL interface in the VFS. Various filesystems may then implement
> more or less of the VFS interface depending on what they support.
> Just as some filesystems implement links and some don't.
ACLs are just far too varied to be combined effectively in a single
API. We support distributed filesystems like AFS in which the server's
notion of who a user is is completely foreign to the kernel's uid/gid
scheme: how do you propose to identify such users when manipulating AFS
ACLs?
--Stephen
Albert D. Cahalan
[about Mandatory Access Control]
> case, what it sounds like you're doing really is trying to protect
> the user from himself, which is not what I generally consider
No, protection from self would be mandatory _default_ controls.
This is rather nice I think, with auditing for overrides...
Mandatory Access Control is intended to hinder spies. If a competitor
wants all your sales contacts, they could use a spy. This spy could
try to email your database out or put it on a Zip disk. Mandatory
access control makes this task very difficult and slow, even if the
spy is allowed to keep a private copy of the database in their home
directory and is allowed to transfer huge files to anywhere desired.
Don't bother with the printer either -- all sheets get marked in huge
letters at top and bottom.
>>> Also, things are
>>> far more complex to review if any user can give access to anyone through
>>> acls. The acls are not seen directly with ls
>>
>> ls is fixable. Possibly by extending "ls -l" to show acl's or at
>> least indicate in some way that acl's are present. The latter may
>> be preferable to avoid script incompatibilities, sonething like this:
>> Arw-r--r-- 1 helge helge 140 Feb 9 1999 .bash_profile
>> The 'A' indicates that acl(s) are present, the user may then use
>> something like "ls --acl" and get the full acl information.
This is already defined by standards and convention.
The standard: add one extra character after the mode
Convention: add a '+' to indicate an ACL
-rw-rw-r-- 1 albert albert 25275 Feb 17 1999 plain-file
-rw-rw-r--+ 1 albert albert 3049 Sep 8 21:06 regular-ACL
-rw-rw-r--/ 1 albert albert 6304 Sep 8 15:51 legal-but-odd
Konrad Rosenbaum
> > ACL interface in the VFS. Various filesystems may then implement
> > more or less of the VFS interface depending on what they support.
> > Just as some filesystems implement links and some don't.
>
> ACLs are just far too varied to be combined effectively in a single
> API. We support distributed filesystems like AFS in which the server's
> notion of who a user is is completely foreign to the kernel's uid/gid
> scheme: how do you propose to identify such users when manipulating AFS
> ACLs?
I know I'm dumb, but what does really vary? The semantics or the rights
you may grant/revoke in the ACL? If it is "only" the semantic design and
implementation shouldn't be difficult.
Could someone just list the types of ACL's spread around here _with_ the
kind of files they allow ACL's on and the right's they allow to set?
Yet I only know NT ACL's (sorry, I haven't worked with real OS'es which
implement ACL's yet). They just seem to be a list of
user/group-plus_minus_access-pairs, so I could imagine a quite simple
ioctl-like syscall for that (it just returns ENOSYS for non-supported
actions), please look at it before complaining :-)
int sys_acl(fd_t fdint mode,...);
where mode may be:
ACL_LOCK makes write-to-acl-actions atomar (only owner and
root may use it)
addition Parameter: ACL_READ, ACL_WRITE, ACL_UNLOCK
ACL_ACTIVATE additional Parameter: boolean to activate or deactivate
the ACL of this file/directory
ACL_GET additional Parameter: number of acl-entry or -1 to return
amount of entries; pointer to a struct s_acl
ACL_SET add.Param.: number of the entry and a struct s_acl
ACL_ADD returns new number
ACL_DELETE add.Param: number of the entry to be deleted
ACL_MOVE add.Param: number of ACL to move, position to move to OR:
ACL_XCHG Params as above, but exchanges these two
struct s_acl{
int type;/*ACL_USER/ACL_GROUP | ACL_GRANT/ACL_REVOKE*/
int ugid;/*UID or GID according to type*/
int access;/*access bits: RWX (for some FS'es Append and others)*/
};
Ok, now the task for everybody who _really_ knows ACL-systems: which FS'es
could _not_ be covered by this syscall and why? What to extend to satisfy
this other FS?
IMHO as far as we have a syscall which satisfies almost all FS'es the
other API's spread around the systems could be emulated in glibc (as with
fork and clone).
happy hacking,
Konrad
Helge Hafting
>
> Hi,
>
> On Tue, 21 Sep 1999 12:13:28 +0200, Helge Hafting
> <helge....@idb.hist.no> said:
>
> > ACL interface in the VFS. Various filesystems may then implement
> > more or less of the VFS interface depending on what they support.
> > Just as some filesystems implement links and some don't.
>
> ACLs are just far too varied to be combined effectively in a single
> API. We support distributed filesystems like AFS in which the server's
> notion of who a user is is completely foreign to the kernel's uid/gid
> scheme: how do you propose to identify such users when manipulating AFS
> ACLs?
I was thinking of local filesystems. If some filesystem have ACLs very
different from what we find useful in a generic VFS interface, then it
cannot be integrated. The VFS would then have to pass ACL operations to
the
fs driver unhandled, or the fs might need its own set of ACL tools
using ioctl.
Helge Hafting
Jeff Haumont
> > > Seems to me that some of this can be solved with a good generic
> > > ACL interface in the VFS. Various filesystems may then implement
> > > more or less of the VFS interface depending on what they support.
> > > Just as some filesystems implement links and some don't.
> >
> > ACLs are just far too varied to be combined effectively in a single
> > API. We support distributed filesystems like AFS in which the server's
> > notion of who a user is is completely foreign to the kernel's uid/gid
> > scheme: how do you propose to identify such users when manipulating AFS
> > ACLs?
>
> I know I'm dumb, but what does really vary? The semantics or the rights
> you may grant/revoke in the ACL? If it is "only" the semantic design and
> implementation shouldn't be difficult.
>
If I am understanding correctly the problem is not the permission mode bits.
I think it would be reasonably easy to come up with a common set of those.
The problem is making a common interface for determining which user/entity
those bits need to be set for. For example, how is it gonna know that
00008997-e0f0-21d0-8100-08005a4728f0, AFS ID 35223, and uid=500(haumont) are
all actually user 'haumont'. It gets even worse with groups, for example
haumont/admin, haumont:admin, and wheel should be the same group on my
machine.
Still, even a bad interface (char *, tell the filesystem you figure it out?)
would be better than nothing ...
Jeff
--
Jeff Haumont <hau...@acm.org>
Erik Bennett
Does the notion of a generic ACL interface in the VFS layer bother
anyone else?
ACLs are nice and everything, and when you need them, there is no
substitute.
But on all of our machines, the vast majority of files need only the
simple, traditional access control mechanisms. Indeed, ACLs for them
would be a security headache.
I've heard that Sun and HP both have security issues because of the
increased complexity in their file systems.
So my question is:
Do the benefits of a generic ACL interface in the VFS layer (should
any exist) justify the increased complexity in the kernel and the
poential increase complexity of secure operation?
Thanks.
-Erik
p.s.
Before you answer (should anyone decide to):
1 - I recognize that no one suggested ACLs for everything.
2 - I recognize that above I said, "on all of our machines", a
somewhat limited sample size.
3 - I recognize that I have no hard data to support my claims about
Sun and HP ACL security trouble. I've only heard of difficulties.
> "Stephen C. Tweedie" wrote:
> >
> > Hi,
> >
> > On Tue, 21 Sep 1999 12:13:28 +0200, Helge Hafting
> > <helge....@idb.hist.no> said:
> >
> > > Seems to me that some of this can be solved with a good generic
> > > ACL interface in the VFS. Various filesystems may then implement
> > > more or less of the VFS interface depending on what they support.
> > > Just as some filesystems implement links and some don't.
> >
> > ACLs are just far too varied to be combined effectively in a single
> > API. We support distributed filesystems like AFS in which the server's
> > notion of who a user is is completely foreign to the kernel's uid/gid
> > scheme: how do you propose to identify such users when manipulating AFS
> > ACLs?
>
> I was thinking of local filesystems. If some filesystem have ACLs very
> different from what we find useful in a generic VFS interface, then it
> cannot be integrated. The VFS would then have to pass ACL operations to
> the
> fs driver unhandled, or the fs might need its own set of ACL tools
> using ioctl.
>
> Helge Hafting
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to majo...@vger.rutgers.edu
> Please read the FAQ at http://www.tux.org/lkml/
-Erik
Erik Bennett ben...@corp.oneworld.com
Michael Bacarella
On Thu, 23 Sep 1999, Jesse Pollard wrote:
> > ls is fixable. Possibly by extending "ls -l" to show acl's or at
> > least indicate in some way that acl's are present. The latter may
> > be preferable to avoid script incompatibilities, sonething like this:
> > Arw-r--r-- 1 helge helge 140 Feb 9 1999 .bash_profile
> > The 'A' indicates that acl(s) are present, the user may then use
> > something like "ls --acl" and get the full acl information.
>
> Due to the possible size of the ACL (it is a list, after all), the UNIX
> ls command should not try to implement a "--acl". They could list up
> to 256 ACL entries, which would definitely be a pain in a "ls -R --acl".
> They only show a flag to indicate an ACL exists. It would be up to the
> user to select an appropriate utility to display the ACL for a file/directory.
>
> Consider: ls is used as a search tool to locate certain files that match a
> pattern. To exend ls to be able to search an ACL to match a pattern would
> be unreasonable; but it is reasonable for a dedicated utility.
This brings up another issue.
Who is allowed to see what ACLs are in place?
I know I would feel pretty insulted if I looked at a friend's ACL and he
gave everyone BUT me LOOKUP access to his directories. It'd also suck
for that person if I found out. :)
--Michael Bacarella
Stephen Frost
> On Thu, 23 Sep 1999, Jesse Pollard wrote:
>
> > > ls is fixable. Possibly by extending "ls -l" to show acl's or at
> > > least indicate in some way that acl's are present. The latter may
> > > be preferable to avoid script incompatibilities, sonething like this:
> > > Arw-r--r-- 1 helge helge 140 Feb 9 1999 .bash_profile
> > > The 'A' indicates that acl(s) are present, the user may then use
> > > something like "ls --acl" and get the full acl information.
> >
> > Due to the possible size of the ACL (it is a list, after all), the UNIX
> > ls command should not try to implement a "--acl". They could list up
> > to 256 ACL entries, which would definitely be a pain in a "ls -R --acl".
> > They only show a flag to indicate an ACL exists. It would be up to the
> > user to select an appropriate utility to display the ACL for a file/directory.
> >
> > Consider: ls is used as a search tool to locate certain files that match a
> > pattern. To exend ls to be able to search an ACL to match a pattern would
> > be unreasonable; but it is reasonable for a dedicated utility.
>
> This brings up another issue.
>
> Who is allowed to see what ACLs are in place?
>
> I know I would feel pretty insulted if I looked at a friend's ACL and he
> gave everyone BUT me LOOKUP access to his directories. It'd also suck
> for that person if I found out. :)
I would hazzard a guess at, if you can read the files, you can read
the ACLs on that file. Otherwise it would be, if you can read the directory,
you can read the ACLs, final thouhts, you have to be on the appropriate ACL
list to read the ACLs. ;) Just a couple thoughts.
Stephen
Casey Schaufler
> Who is allowed to see what ACLs are in place?
>
> I know I would feel pretty insulted if I looked at a friend's ACL and he
> gave everyone BUT me LOOKUP access to his directories. It'd also suck
> for that person if I found out. :)
One classic example for how you'd use ACLs is the Surprise Birthday
Party Announcement, for which you want to grant everyone in a group
read access except the guest of honor. There, does that help you
feel better? Maybe they've gotten you a nice cake!
When we evaluated Irix (at B1) we had to address the issues of
access control policy, including why it was that a user might be
able to see the permission bit on a file that she couldn't read.
We explained it thus:
Access to a file system object (e.g. a file) is controlled by
a set of policies:
PATH-DATA-READ
The path leading to the object must be composed
of readable objects.
The MAC label of the subject (e.g. process) must
dominate that of the object.
The DAC permissions (e.g. permission bits, ACL)
on the object must allow read.
PATH-DATA-WRITE
The path leading to the object must be composed
of readable objects.
The MAC label of the subject (e.g. process) must
dominate that of the object.
The DAC permissions (e.g. permission bits, ACL)
on the object must allow write.
PATH-ATTRIBUTE-READ
The path leading to the object must be composed
of readable objects.
The MAC label of the subject (e.g. process) must
dominate that of the object.
PATH-ATTRIBUTE-WRITE
The path leading to the object must be composed
of readable objects.
The MAC label of the subject (e.g. process) must
dominate that of the object.
The owner of the subject must be the owner of the
object.
FD-DATA-READ
Access is permitted.
FD-DATA-WRITE
Access is permitted to the extent granted on open().
FD-ATTRIBUTE-READ
Access is permitted.
FD-ATTRIBUTE-WRITE
The owner of the subject must be the owner of the
object.
The access to the attributes of a file are controlled differently
from the access to the data of a file. Short of using an additional
scheme such as MAC, there is no way to prevent someone from reading
the attributes for a file without using the attributes of another
object (a containing directory).
You could decide that an ACL is a "special attribute", with yet
another access control policy. I'd be interested in a policy that
makes sense. If you say check the ACL, I'll refer you to MAC.
--
Casey Schaufler voice: (650) 933-1634
ca...@sgi.com fax: (650) 933-0170
-
Joel Becker
> On Fri, 24 Sep 1999, Michael Bacarella wrote:
>
> > This brings up another issue.
> >
> >
> > I know I would feel pretty insulted if I looked at a friend's ACL and he
> > gave everyone BUT me LOOKUP access to his directories. It'd also suck
> > for that person if I found out. :)
>
> the ACLs on that file. Otherwise it would be, if you can read the directory,
> you can read the ACLs, final thouhts, you have to be on the appropriate ACL
> list to read the ACLs. ;) Just a couple thoughts.
>
> Stephen
On AIX and in DCE/DFS, ACLs are shown with their own command
("acl_edit -l", "lsacl", or the like). They are viewable by anyone
(just like permissions). They are only changeable by people with the
correct ACL to change ('c' in DFS).
True, you might get upset if your friend has denied only you. But
chances are there is a reason, and you'll already know why :-)
I've been pretty happy with the flexibility and granularity of
ACLs in DFS (they are per-file, btw). The accessing tool, dcecp, is
awkward, but I have fixed that with ls/chmod workalikes lsacl and
chacl.
Joel
--
"Don't worry, leave everything to me! Cling tenaciously to my buttocks!"
jl...@evilplan.org
http://ocala.cs.miami.edu/~jlbec
Stephen Frost
> On Fri, Sep 24, 1999 at 05:47:34PM -0400, Stephen Frost wrote:
> > On Fri, 24 Sep 1999, Michael Bacarella wrote:
> >
> > > This brings up another issue.
> > >
> > > Who is allowed to see what ACLs are in place?
> > >
> > > I know I would feel pretty insulted if I looked at a friend's ACL and he
> > > gave everyone BUT me LOOKUP access to his directories. It'd also suck
> > > for that person if I found out. :)
> >
> > I would hazzard a guess at, if you can read the files, you can read
> > the ACLs on that file. Otherwise it would be, if you can read the directory,
> > you can read the ACLs, final thouhts, you have to be on the appropriate ACL
> > list to read the ACLs. ;) Just a couple thoughts.
> >
> > Stephen
>
> On AIX and in DCE/DFS, ACLs are shown with their own command
> ("acl_edit -l", "lsacl", or the like). They are viewable by anyone
> (just like permissions). They are only changeable by people with the
> correct ACL to change ('c' in DFS).
> True, you might get upset if your friend has denied only you. But
> chances are there is a reason, and you'll already know why :-)
> I've been pretty happy with the flexibility and granularity of
> ACLs in DFS (they are per-file, btw). The accessing tool, dcecp, is
> awkward, but I have fixed that with ls/chmod workalikes lsacl and
> chacl.
Then like permissions, if you don't have access to the directory,
you can't see the permissions on a file inside the directory. :) The only
problem with this of course being, if you use ACLs on your directory, and
your friend can see that... :)
Stephen
Bear Giles
> Coda, NTFS, etc., all have different ACL semantics. For example, AFS
> only has an ACL on a per-directory basis. I'm not sure about Coda, but
> it may be the same as AFS. NTFS uses 128 bit UUID's in its ACL's to
> name users and groups. The POSIX acl interface uses uid_t and gid_t for
> user and group id's.
Since I haven't seen anyone else ask this...
... why are we worried about compatibility with NTFS? Or with distributed
file systems?
I'm not arguing that such support isn't a good idea, only that we seem
to be putting the cart before the horse here. Let's get *native* ACL
support into our filesystems. By "native" I mean that it uses the same
information we already require filesystems to understand (uid_t, gid_t).
N.B., as I understand ACLs they will be enforced by the file system
module, not the general kernel VFS level or user libraries. Unless
I'm mistaken the only extensions required to the VFS level are:
struct acl {
uid_t uid; /* uid or UID_ANY */
gid_t gid; /* gid or GID_ANY */
int permissions; /* R_OK, W_OK, X_OK, etc. */
};
ssize_t write_acls (int mode, const struct acl *acls, size_t size);
ssize_t read_acls (int mode, struct acl *acls, size_t size);
where mode = 0 for discretionary access control (user can modify)
and mode = 1 for non-discretionary access control (user can't modify,
but root or CAPACITY_NDAC(?) can.)
You don't need to have "positive" and "negative" flags if you follow
the policy that the best match dominates. You could remove 'bob' from
your group's permissions by:
(bob,group: ---)
(%,group: rw-)
Finally, once that's stable we can decide how to handle non-native ACLs
(e.g., those that require 128-bit UUIDs). We might lose some of the
transparency that VFS is intended to provide, but that's an unfortunate
reflection of the tremendous variety in how different groups handle ACLs.
I would hate to see us delay ACLs for months so we can handle NTFS,
only to have that filesystem be changed in a way that invalidates the
work.
Bear Giles
bgi...@coyotesong.com
Jesse Pollard
>
> > > Seems to me that some of this can be solved with a good generic
> > > ACL interface in the VFS. Various filesystems may then implement
> > > more or less of the VFS interface depending on what they support.
> > > Just as some filesystems implement links and some don't.
> >
> > ACLs are just far too varied to be combined effectively in a single
> > API. We support distributed filesystems like AFS in which the server's
> > notion of who a user is is completely foreign to the kernel's uid/gid
> > scheme: how do you propose to identify such users when manipulating AFS
> > ACLs?
>
> you may grant/revoke in the ACL? If it is "only" the semantic design and
> implementation shouldn't be difficult.
The list of access rights vary depending on the implementation: you may
be able to access a file, but not create it (access to directory), you may
have write access, but not delete - both depend on some form of directory
write: but the host file system may not have W as a permission to a directory.
(this is NOT a unix filesystem being accessed over a net...)
> Could someone just list the types of ACL's spread around here _with_ the
> kind of files they allow ACL's on and the right's they allow to set?linux-...@vger.rutgers.edu
>
> Yet I only know NT ACL's (sorry, I haven't worked with real OS'es which
> implement ACL's yet). They just seem to be a list of
> user/group-plus_minus_access-pairs, so I could imagine a quite simple
> ioctl-like syscall for that (it just returns ENOSYS for non-supported
> actions), please look at it before complaining :-)
It can't depend on an IOCTL type interface - you may not be able to open
the file but may be able to read the access list.
> int sys_acl(fd_t fdint mode,...);
>
> where mode may be:
> ACL_LOCK makes write-to-acl-actions atomar (only owner and
> root may use it)
> addition Parameter: ACL_READ, ACL_WRITE, ACL_UNLOCK
> ACL_ACTIVATE additional Parameter: boolean to activate or deactivate
> the ACL of this file/directory
> ACL_GET additional Parameter: number of acl-entry or -1 to return
> amount of entries; pointer to a struct s_acl
> ACL_SET add.Param.: number of the entry and a struct s_acl
> ACL_ADD returns new number
> ACL_DELETE add.Param: number of the entry to be deleted
> ACL_MOVE add.Param: number of ACL to move, position to move to OR:
> ACL_XCHG Params as above, but exchanges these two
>
> struct s_acl{
> int type;/*ACL_USER/ACL_GROUP | ACL_GRANT/ACL_REVOKE*/
> int ugid;/*UID or GID according to type*/
> int access;/*access bits: RWX (for some FS'es Append and others)*/
> };
>
> Ok, now the task for everybody who _really_ knows ACL-systems: which FS'es
> could _not_ be covered by this syscall and why? What to extend to satisfy
> this other FS?
NTFS - UUID references are 128 bits, access rights can be much larger than
RWX (It appears to be a more generic attribute storage that happens to
contain ACLs proper - this is from cursory investigation (some of
them use symbolic names for rights not directly related to access, I
could be wrong... details at 11?:).
DCE - user reference is a symbolic name, not a uid (at least it was the
last time I had the DCE class.
There can be access control lists that control access to applications. The
internal structure of these lists are drastically different from the simple
case of file access (kerberos ACLs for instance).
Kerberos (yes they are ACLs, just interpreted differently)
AFS/Coda (don't know - haven't had access to these)
Also, some ACLs can cascade - It is usually better to replace the entire
list in one atomic operation, otherwise - editing an ACL becomes very difficult
to do correctly.
> IMHO as far as we have a syscall which satisfies almost all FS'es the
> other API's spread around the systems could be emulated in glibc (as with
> fork and clone).
what system call? As far as I have seen, it doesn't esist (yet).
What I had envisioned is:
1. Limits
a. Several different classes of acl:
1. AFS/Coda/DFS
a. ACLs on directories only
b. Network distributed
c. Enforced on server
2. POSIX
a. ACLs on directories and files
b. local to host
c. enforced on host - may or may not be passed to remote server
(as in NFS - that requires changes to NFS protocol)
b. Different Semantics - its almost as if ACLs as a title are describing
different facilities.
2. Initial focus should be on POSIX ACLs, but care to be taken
to prevent excluding others:
a. impose the minimum of policy as possible
b. provide generic facilities where ever possible
1. Just as the "fsck" utility selects the appropriate repair
utility by inspecting the filesystem, the ACL edit should
select the appropriate ACL edit for the given filesystem.
2. The kernel should provide a data path from the filesystem
to the edit facliity
3. The kernel should not impose an interpretation on the data
provided by the edit capability - that will be the job of
the filesystem layer.
c. To allow for efficient implementation:
1. The entire ACL should be transfered to/from the file system
in one block. Individual ACL entry modifications would make
the file system implementation too large and slow.
2. A variable sized ACL implementation can be supported by using
the filesystem type to inform the user of the given limits.
3. Initial Proposal:
a. Semantic interpretation of the given ACL will be up to the
existing VFS permissions function.
b. A minimum of one additional VFS function in the
inode_operations structure (alternatively there could be one
for each of the ACL operations; I view this as supporting only one
new system call):
return_status = acl_access(inode,operation,buffer,length)
where:
inode - the inode being queried
operation - the ACL action to take
buffer - ACL data transfer buffer
length - length of the buffer (bytes)
return_status - error number:
ENOSYS - ACL not implemented
EINVAL - ACL larger than buffer
(get)
input ACL too large (put)
Note: It is not necessary to open the file before accessing the
ACL (use a pathname specification). This is undesirable since
some ACL structures can only be applied to directories.
The operations that can be carried out are:
status - fill the data buffer with:
return file system type
size of single ACL entry (in bytes)?
length of ACL (0 => no ACL)
maximum size of ACL
get ACL - fill buffer with:
file system type
length of ACL (0 => no ACL)
contents of ACL
put ACL - replace the current ACL with the data in the buffer
file system type
length of ACL (0 => delete ACL)
contents of ACL
I view the "length of ACL" to be the bytelength of the entire list
and can be used to create a buffer large enough to hold the ACL.
Note: the get/put operations should be atomic if implemented locally.
Network synchronization is always a coin toss.
c. library manipulation functions (application level access):
acl_get - get acl list into memory
acl_first - return pointer to first acl entry
acl_next - return pointer to next acl (null => end of list)
acl_add - insert ACL at current pointer position (null current
pointer means add to the end of the list)
acl_del - remove ACL at current pointer position.
acl_put - replace the active acl with the updated list. If list
not modified then do nothing.
Note: the acl library functions will have to be fairly intelligent
to be able to parse the various ACL definitions. I don't know
a set of parameters yet.
4. Auditing (this is preliminary rabble-rousing stuff:)
a. Each file system will have to use a centralized audit log function.
The Audit log should contain (even if not done directly by the
file system code. Data from the file system will be merged with
a base record):
base record:
time stamp
host
user
I/O record:
function (all I/O requests)
log information (data reference if any)
status (returned status code)
-------------------------------------------------------------------------
Jesse I Pollard, II
Email: pol...@navo.hpc.mil
Any opinions expressed are solely my own.
-
Jesse Pollard
...
>Finally, once that's stable we can decide how to handle non-native ACLs
>(e.g., those that require 128-bit UUIDs). We might lose some of the
>transparency that VFS is intended to provide, but that's an unfortunate
>reflection of the tremendous variety in how different groups handle ACLs.
>I would hate to see us delay ACLs for months so we can handle NTFS,
>only to have that filesystem be changed in a way that invalidates the
>work.
The problem is that selecting a very minimalist implementation too early
can force a complete redesign replacement later. If we try to keep it
down to just a block of data , and allow the individual filesystems to
determine the semantic interpretation then we can implement any kind of
ACL desired, and not have to replace everything.
Richard Dynes
Hello-
I have the tulip driver in debug mode (insmod tulip debug=6).
Previously (Linux 2.3.11 and prior), the messages came out in
/var/log/messages. Now they show up in multiple xterm sessions,
regardless of the UID of the user logged in. So I get the same
messages in 4 windows at once.
How do I control this / turn it off?
Linux 2.3.18ac8...
-Richard
--
Richard Dynes
rdy...@varcom.com
Bear Giles
> ...
> >Finally, once that's stable we can decide how to handle non-native ACLs
> >(e.g., those that require 128-bit UUIDs).
>
> can force a complete redesign replacement later.
Granted, but it seemed that the "what about NTFS" thread was getting
out of control. Why would you ever read a NTFS disk on a Linux system
unless you're dual booting, and why would you care about ACLs in that
case? (Security 101: you can't guarantee anything if you don't have
physical control of the system. It would be nice if we honored NTFS
ACLs, but we shouldn't be trusting NT applications to honor *ours*.)
Once you get that out of the way it seems that everything falls into
one of three cases: it's either a local Linux-like disk or it's a
remote/distributed disk. Remote/distributed file systems will either
have ownership and permissions which can be clearly mapped to ours, or
they won't. It's only the last case where we will have problems, and
we would have problems in any case. (E.g., do we force all file systems
to carry an extra 2k of code to support an obscure FS's semantics?)
Bear Giles
bgi...@coyotesong.com
(P.S., I know that you could put NTFS on removable media, so the
"dual boot" argument isn't watertight. But the "physical control
of the media" problem remains - nobody using ACLs should depend on
those ACLs being honored once the media leaves their control.)
Jesse Pollard
> > From: Bear Giles <be...@coyotesong.com>
> > ...
> > >Finally, once that's stable we can decide how to handle non-native ACLs
> > >(e.g., those that require 128-bit UUIDs).
> >
> > The problem is that selecting a very minimalist implementation too early
> > can force a complete redesign replacement later.
>
> Granted, but it seemed that the "what about NTFS" thread was getting
> out of control. Why would you ever read a NTFS disk on a Linux system
> unless you're dual booting, and why would you care about ACLs in that
> case? (Security 101: you can't guarantee anything if you don't have
> physical control of the system. It would be nice if we honored NTFS
> ACLs, but we shouldn't be trusting NT applications to honor *ours*.)
NT doesn't - I haven't seen any NT system mount filesystems that MS didn't
develop. This does NOT refer to samba - that makes OUR file system look like
THEIRS, and yes it would be good to support NT ACLs in that case.
> Once you get that out of the way it seems that everything falls into
> one of three cases: it's either a local Linux-like disk or it's a
> remote/distributed disk. Remote/distributed file systems will either
> have ownership and permissions which can be clearly mapped to ours, or
> they won't. It's only the last case where we will have problems, and
> we would have problems in any case. (E.g., do we force all file systems
> to carry an extra 2k of code to support an obscure FS's semantics?)
1. The distributed file system may come from a Linux server - It would then
be a Good Thing to support any ACLs on the distributed file system
(NFS/Coda? If NFS then the underlying file system may have ACLs)
2. The outline I provided does not "force" any ACL support. If it isn't
supported then the value ENOSYS should be returned to indicate
that it doesn't exist.
I tried to lay out a proposal that doesn't impose any constraints on the
ACL implementation in the kernel. The filesystem layer should make that
determination.
I also didn't mandate an external daemon to perform translation services, but
one could be used. The application library/editor could communicate with
a daemon for translations, that would be up to the library/editor.
> Bear Giles
> bgi...@coyotesong.com
>
> (P.S., I know that you could put NTFS on removable media, so the
> "dual boot" argument isn't watertight. But the "physical control
> of the media" problem remains - nobody using ACLs should depend on
> those ACLs being honored once the media leaves their control.)
Yup. Didn't mean to imply that removable media was any different - but
consider:
20GB IDE/SCSI removable disk sleds. IF the facility provides for
secure storage then the ACLs (and MAC labels too) are also secure.
We have labeled removable media here (file migration to 50GB tapes) and in
a secure facility. Labels can still be trusted since users cannot get their
hands on it. 27TB of data cannot all be stored on non-removable disks (at
least not yet).
-------------------------------------------------------------------------
Jesse I Pollard, II
Email: pol...@navo.hpc.mil
Any opinions expressed are solely my own.
-
Jesse Pollard
There is a POSIX style implementation of ACLs on Ext2fs that could be ported
to Ext3. See:
http://major.rithus.co.at/acl/
There is documentation and references to other projects included.
Thanks all.