On Tue 2008-02-19 09:00:08, Paul Jackson wrote:
> Kosaki-san wrote:
> > Thank you for wonderful interestings comment.
>
> You're most welcome. The pleasure is all mine.
>
> > you think kill the process just after swap, right?
> > but unfortunately, almost user hope receive notification before sw
On Sat 2008-02-09 11:07:09, Jon Masters wrote:
> This really needs to be triggered via a generic kernel
> event in the final version - I picture glibc having a
> reservation API and having generic support for freeing
> such reservations.
Not sure what you are talking about. This seems very ri
On Fri 2008-01-25 11:42:29, Theodore Tso wrote:
> On Fri, Jan 25, 2008 at 10:34:25AM -0600, Eric Sandeen wrote:
> > > But it was this concern which is why ext3 never exported freeze
> > > functionality to userspace, even though other commercial filesystems
> > > do support this. It wasn't that it
On Mon 2008-01-28 14:56:33, Theodore Tso wrote:
> On Mon, Jan 28, 2008 at 07:30:05PM +0000, Pavel Machek wrote:
> >
> > As user pages are always in highmem, this should be easy to decide:
> > only send SIGDANGER when highmem is full. (Yes, there are
> > inodes/dentries
Hi!
> It's been discussed before, but I suspect the main reason why it was
> never done is no one submitted a patch. Also, the problem is actually
> a pretty complex one. There are a couple of different stages where
> you might want to send an alert to processes:
>
> * Data is starting to g
On Sun 2008-01-20 09:23:00, Miklos Szeredi wrote:
> > Miklos Szeredi wrote:
> > > - for mount ID's use IDA (from the IDR library) instead of a 32bit
> > > counter, which could overflow
> >
> > IDAs tend to get reused quickly, which can cause race conditions. Any
> > reason not to just use a 64
Hi!
> > I guess I should try to measure it. (Linux already does writeback
> > caching, with 2GB of memory. I wonder how important disks's 2MB of
> > cache can be).
>
> It serves essentially the same purpose as the 'async' option in /etc/exports
> (i.e. we declare it "done" when the other end of t
On Tue 2008-01-15 20:36:16, Chris Mason wrote:
> On Tue, 15 Jan 2008 20:24:27 -0500
> "Daniel Phillips" <[EMAIL PROTECTED]> wrote:
>
> > On Jan 15, 2008 7:15 PM, Alan Cox <[EMAIL PROTECTED]> wrote:
> > > > Writeback cache on disk in iteself is not bad, it only gets bad
> > > > if the disk is not e
On Tue 2008-01-15 18:44:26, Daniel Phillips wrote:
> On Jan 15, 2008 6:07 PM, Pavel Machek <[EMAIL PROTECTED]> wrote:
> > I had write cache enabled on my main computer. Oops. I guess that
> > means we do need better documentation.
>
> Writeback cache on disk in itese
Hi!
> Along with this effort, could you let me know if the world actually
> cares about online fsck?
I'm not the world's spokeperson (yet ;-).
> Now we know how to do it I think, but is it
> worth the effort.
ext3's "lets fsck on every 20 mounts" is good idea, but it can be
annoying when deve
Hi!
> > > > What are ext3 expectations of disk (is there doc somewhere)? For
> > > > example... if disk does not lie, but powerfail during write damages
> > > > the sector -- is ext3 still going to work properly?
> > >
> > > Nope. However the few disks that did this rapidly got firmware updates
>
ly numbered. The
> usually are but you never know.
Ok, should something like this be added to the documentation?
It would be cool to be able to include few examples (modern SATA disks
support bariers so are safe, any IDE from 1989 is unsafe), but I do
not know enough about hw...
Signed-off-
On Sat 2008-01-12 09:51:40, Theodore Tso wrote:
> On Wed, Jan 09, 2008 at 02:52:14PM +0300, Al Boldi wrote:
> >
> > Ok, but let's look at this a bit more opportunistic / optimistic.
> >
> > Even after a black-out shutdown, the corruption is pretty minimal, using
> > ext3fs at least.
> >
>
> Aft
On Wed 2008-01-09 14:48:53, Miklos Szeredi wrote:
> > I'm not saying fuse is worthless. It is a nice toy for single-user
> > systems. But I do not think we should be merging "allow ordinary users
> > to mount their own fuse's" before issues above are fixed.
>
> I think multi user systems are not a
Hi!
> > ...this will break with FUSE enabled, right? (Minor security hole by
> > allowing users to stop c-a-delete, where none existed before?)
>
> Yup (or I don't know, I'm sure there was or is some problem with
> ptrace, that could be used to create unkillable processes).
>
> Fuse could actual
Hi!
> > > AFAIR there were two security vulnerabilities in fuse's history, one
> > > of them an information leak in the kernel module, and the other one an
> > > mtab corruption issue in the fusermount utility. I don't think this
> > > is such a bad track record.
> >
> > Not bad indeed. But I'd
On Wed 2008-01-09 09:47:31, Miklos Szeredi wrote:
> > >> On Tue 2008-01-08 12:35:09, Miklos Szeredi wrote:
> > >>> From: Miklos Szeredi <[EMAIL PROTECTED]>
> > >>>
> > >>> Use FS_SAFE for "fuse" fs type, but not for "fuseblk".
> > >>>
> > >>> FUSE was designed from the beginning to be safe for unpr
On Tue 2008-01-08 23:42:20, Miklos Szeredi wrote:
> > On Tue 2008-01-08 12:35:09, Miklos Szeredi wrote:
> > > From: Miklos Szeredi <[EMAIL PROTECTED]>
> > >
> > > Use FS_SAFE for "fuse" fs type, but not for "fuseblk".
> > >
> > > FUSE was designed from the beginning to be safe for unprivileged us
On Tue 2008-01-08 12:35:03, Miklos Szeredi wrote:
> From: Miklos Szeredi <[EMAIL PROTECTED]>
>
> This patchset adds support for keeping mount ownership information in the
> kernel, and allow unprivileged mount(2) and umount(2) in certain cases.
>
> The mount owner has the following privileges:
>
On Tue 2008-01-08 12:35:09, Miklos Szeredi wrote:
> From: Miklos Szeredi <[EMAIL PROTECTED]>
>
> Use FS_SAFE for "fuse" fs type, but not for "fuseblk".
>
> FUSE was designed from the beginning to be safe for unprivileged users. This
> has also been verified in practice over many years. In addit
On Tue 2008-01-08 12:35:03, Miklos Szeredi wrote:
> From: Miklos Szeredi <[EMAIL PROTECTED]>
>
> This patchset adds support for keeping mount ownership information in the
> kernel, and allow unprivileged mount(2) and umount(2) in certain cases.
>
> The mount owner has the following privileges:
>
> Why not use SELinux?
>
> Because SELinux doesn't guarantee filename and its attribute.
> The purpose of this filesystem is to ensure filename and its attribute
> (e.g. /dev/null is guaranteed to be a character device file
> with major=1 and minor=3).
Why not improve selinux to be able to a
Hi!
> Remove the need for having CAP_SYS_RAWIO when doing a FIBMAP call on an open
> file descriptor.
>
> It would be nice to allow users to have permission to see where their data is
> landing on disk, and there really isn't a good reason to keep them from
> getting at this information.
I be
Hi!
> I'm pleased to announce third release of the distributed storage
> subsystem, which allows to form a storage on top of remote and local
> nodes, which in turn can be exported to another storage as a node to
> form tree-like storages.
How is this different from raid0/1 over nbd? Or raid0/1 o
Hi!
> > > I wouldn't bother with setting the directory type field to be DT_WHT,
> > > given that they will never be returned to userspace anyway.
> >
> > At the moment I still rely on this for the current readdir implementation.
> > Viro already said that he doesn't want to see this (the readdir
Hi!
> > ... or, alternatively, add a subfield to the first field (which would
> > entail escaping whatever separator we choose):
> >
> > /dev/md6 /export ext3 rw,data=ordered 0 0
> > /dev/md6:/users/foo /home/foo ext3 rw,data=ordered 0 0
> > /dev/md6:/users/bar /home/bar ext3 rw,data=ordered 0 0
Hi!
> We've been over the "AA is different" discussion in threads about a
> billion times, and at the last kernel summit. I think Lars and others
> have done a pretty good job of describing the problems they are trying
> to solve, can we please move on to discussing technical issues around
> that
Hi!
> But as someone who doesn't use either SElinux or AA, I really hope
> we can get past the part of the debate where:
>
> while(1)
> AA) we think we're making users happy with pathname security
> SELINUX) pathname security sucks
(Hopefully I'll not be fired for this. :-)
Yes, we _are
Hi!
> > I believe AA breaks POSIX, already. rename() is not expected to change
> > permissions on target, nor is link link. And yes, both of these make
> > AA insecure.
>
> AA is supposed to allow valid access patterns, so for non-buggy apps +
> policies, the rename will be fine and does not chan
Hi!
> >>The code has improved, and continues to improve, to meet all the coding
> >>style feedback except the bits which are essential to AA's function
> >
> >Which are exactly the bits Christoph Hellwig and Al Viro
> >vetoed. http://www.uwsg.iu.edu/hypermail/linux/kernel/0706.1/2587.html
> >. I b
Hi!
> I've caught up on this thread with growing disbelief while reading the
> mails, so much that I've found it hard to decide where to reply to.
>
> So people are claiming that AA is ugly, because it introduces pathnames
> and possibly a regex interpreter. Ok, taste differs. We've got many
> di
On Thu 2007-06-21 18:01:05, Andreas Gruenbacher wrote:
> On Saturday 16 June 2007 01:49, Greg KH wrote:
> > But for those types of models that do not map well to internal kernel
> > structures, perhaps they should be modeled on top of a security system that
> > does handle the internal kernel repre
Hi!
> >>Under the restorecon proposal, the web site would be horribly broken
> >>until restorecon finishes, as various random pages are or are not
> >>accessible to Apache.
> >
> >Usually you don't do that by doing a 'mv' otherwise you are almost
> >guaranteed stale and mixed up content for some p
Hi!
> >> Only case where attacker _can't_ be keeping file descriptors is newly
> >> created files in recently moved tree. But as you already create files
> >> with restrictive permissions, that's okay.
> >>
> >> Yes, you may get some -EPERM during the tree move, but AA has that
> >> problem alread
Hi!
> > Yes, you may get some -EPERM during the tree move, but AA has that
> > problem already, see that "when madly moving trees we sometimes
> > construct path file never ever had".
>
> Pavel, please focus on the current AppArmor implementation. You're
> remembering a flaw with a previous versi
Hi!
And before you scream "races", take a look. It does not actually add
them:
> > > I agree that the in-kernel implementation could use different
> > > abstractions
> > > than user-space, provided that the underlying implementation details can
> > > be
> > > hidden well enough. The key phras
Hi!
> > > > How will kernel work with very long paths? I'd suspect some problems,
> > > > if path is 1MB long and I attempt to print it in /proc
> > > > somewhere.
> > >
> > > Pathnames are only used for informational purposes in the kernel, except
> > > in AppArmor of course. /proc only uses pa
Hi!
> ACPI should have taught everyone that sometimes putting an interpreter in
> the kernel really is the best option. looking at the problems of bouncing
> back out to userspace for file creation and renames it looks like a regex
> in the kernel is a lot safer and more reliable.
What do ACPI
Hi!
> >>extended out this can come close to giving each file it's own label. AA
> >>essentially does this and calls the label the path and computes it at
> >>runtime instead of storing it somewhere.
> >
> >Yes, and in the process, AA stores compiled regular expressions in
> >kernel. Ouch. I'll tak
Hi!
> >So, AA developers, do you have such a document anywhere? I know there
> >are some old research papers, do they properly describe the current
> >model you are trying to implement here?
>
> Greg,
> to implement the AA approach useing SELinux you need to have a way that
> files that are r
Hi!
> I'm not sure if AppArmor can be made good security for the general case,
> but it is a model that works in the limited http environment
> (eg .htaccess) and is something people can play with and hack on and may
> be possible to configure to be very secure.
>
> >>>Perhaps
Hi!
> >> I'm not sure if AppArmor can be made good security for the general case,
> >> but it is a model that works in the limited http environment
> >> (eg .htaccess) and is something people can play with and hack on and may
> >> be possible to configure to be very secure.
> >>
> > Perhaps -
Hi!
> >> Some may infer otherwise from your document.
> >>
> > Not only that, the implication that secrecy is only useful to
> > intelligence agencies is pretty funny.
> That was not the claim. Rather, that intelligence agencies have a very
> strong need for privacy, and will go to greater le
Hi!
> > How will kernel work with very long paths? I'd suspect some problems,
> > if path is 1MB long and I attempt to print it in /proc
> > somewhere.
>
> Pathnames are only used for informational purposes in the kernel, except in
> AppArmor of course. /proc only uses pathnames in a few places,
Hi!
> > > You very well know that the vfs has a limit of PATH_MAX characters (4096)
> > > for pathnames. This means that at most that many characters can be passed
> > > at once.
>
> What users can do is something like this:
>
> chdir("some/long/path");
> chdir("some/even/longer/path");
>
On Mon 2007-06-04 13:25:30, Andreas Gruenbacher wrote:
> On Monday 04 June 2007 12:55, Pavel Machek wrote:
> > On Wed 2007-05-23 18:16:45, Andreas Gruenbacher wrote:
> > > On Tuesday 15 May 2007 11:14, Pavel Machek wrote:
> > > > Why is this configurable?
>
On Wed 2007-05-23 18:16:45, Andreas Gruenbacher wrote:
> On Tuesday 15 May 2007 11:14, Pavel Machek wrote:
> > Why is this configurable?
>
> The maximum length of a pathname is an arbitrary limit: we don't want to
> allocate arbitrary amounts of of kernel memory for pa
Hi!
> >> Average users are not supposed to be writing security policy. To be
> >> honest, even average-level system administrators should not be
> >> writing security policy.
> That explains so much! "SELinux: you're too dumb to use it, so just keep
> your hands in your pockets." :-)
>
> App
Hi!
> >>That's a circular argument, and a fairly trivial one
> >>at that. If you
> >>can't properly manage your labels, then how do you
> >>expect any
> >>security at all?
> >
> >Unfortunately, it's not at all as simple as all that.
> >Toshiharu is quite correct that it isn't always easy
> >
Hi!
> > As for unlink... How do you deal with having that thing
> > mounted, mounting something _under_ it (so that vfsmount would be kept
> > busy) and then unlinking that sucker?
>
> Yeah, that's a good point. Current patch doesn't deal with that.
> Simplest solution could be to disallow subm
Hi!
> >Yes. These things are almost always implemented _very_
> >badly by the same
> >kind of crack-smoking hobo they drag in off the streets
> >to write BIOSen.
> >
> >It's bog-roll technology; if you fancy a laugh try
> >doing some real
> >reliability tests on them time some. Powerfail testin
> >> My experience is that no matter which name I pick,
> >people will
> >> complain
> >> anyway. Previous suggestions included:
> >> jffs3
> >> jefs
> >> engelfs
> >> poofs
> >> crapfs
> >> sweetfs
> >> cutefs
> >> dynamic journaling fs - djofs
> >> tfsfkal - the file system formerly known as l
Hi!
In kernel fsck
> --- /dev/null 2007-04-18 05:32:26.652341749 +0200
> +++ linux-2.6.21logfs/fs/logfs/progs/fsck.c 2007-05-15 00:54:22.0
> +0200
> @@ -0,0 +1,332 @@
> +/*
> + * fs/logfs/prog/fsck.c - filesystem check
> + *
> + * As should be obvious for Linux kernel code, li
Hi!
> Pathname matching, transition table loading, profile loading and
> manipulation.
So we get small interpretter of state machines, and reason we need is
is 'apparmor is misdesigned and works with paths when it should have
worked with handles'.
If you solve the 'new file problem', aa becomes
Hi!
> Set the LOOKUP_CONTINUE flag when checking parent permissions. This allows
> permission functions to tell between parent and leaf checks.
>
> Signed-off-by: Andreas Gruenbacher <[EMAIL PROTECTED]>
I guess you should sign this off.
> --- a/fs/namei.c
> +++ b/fs/namei.c
> @@ -1409,6 +1409,
Hi!
> The underlying functions by which the AppArmor LSM hooks are implemented.
>
> Signed-off-by: John Johansen <[EMAIL PROTECTED]>
> Signed-off-by: Andreas Gruenbacher <[EMAIL PROTECTED]>
> +#include "inline.h"
Select a better name for include?
> +static inline void aa_permerror2result(int p
> Module parameters, LSM hooks, initialization and teardown.
>
> Signed-off-by: John Johansen <[EMAIL PROTECTED]>
> Signed-off-by: Andreas Gruenbacher <[EMAIL PROTECTED]>
> +/* Maximum pathname length before accesses will start getting rejected */
> +unsigned int apparmor_path_max = 2 * PATH_MAX
Hi!
> "Serge E. Hallyn" <[EMAIL PROTECTED]> wrote:
>
> > Following are two patches which have been sitting for some time in -mm.
>
> Where "some time" == "nearly six months".
>
> We need help considering, reviewing and testing this code, please.
I did quick scan, and it looks ok. Plus, it mean
Hi!
> For some time I had been working on this file system
> test framework.
> Now I have a implementation for the same and below is
> the explanation.
> Any comments are welcome.
>
> Introduction:
> The testing tools and benchmarks available around do not
> take into
> account the repair and
Hi!
> > > +
> > > + /* get optional subprofiles */
> > > + if (aa_is_nameX(e, AA_LIST, "hats")) {
> > > + while (!aa_is_nameX(e, AA_LISTEND, NULL)) {
> > > + struct aa_profile *subprofile;
> > > + subprofile = aa_unpack_profile(e);
> >
> > Is there any chec
Hi!
> AppArmor's Overall Design
> =
>
> AppArmor protects systems from vulnerable software by confining
> processes, giving them "least privilege" access to the system's
> resources: with least privilege, processes are allowed exactly what they
> need, nothing more, and no
Hi!
> > > That statement is meant to scare people away from modifying the lower fs
> > > :)
> > > I tortured unionfs quite a bit, and it can oops but it takes some effort.
> > But isn't it then potential DOS? If you happen to union two filesystems
> > and an untrusted user has write access to b
On Tue 2007-01-09 15:43:14, Bryan Henderson wrote:
> >but you can get a large number of >1 linked
> >files, when you copy full directories with "cp -rl". Which I do a lot
> >when developing. I've done that a few times with the Linux tree.
>
> Can you shed some light on how you use this technique?
Hi!
> > >> No one guarantees you sane result of tar or cp -a while changing the
> > >> tree.
> > >> I don't see how is_samefile() could make it worse.
> > >
> > > There are several cases where changing the tree doesn't affect the
> > > correctness of the tar or cp -a result. In some of these cas
On Fri 2007-01-05 16:15:41, Miklos Szeredi wrote:
> > > And does it matter? If you rename a file, tar might skip it no matter of
> > > hardlink detection (if readdir races with rename, you can read none of
> > > the
> > > names of file, one or both --- all these are possible).
> > >
> > > If yo
Hi!
> > > > Some of us have machines designed to cope with cosmic rays, and would be
> > > > unimpressed with a decrease in reliability.
> > >
> > > With the suggested samefile() interface you'd get a failure with just
> > > about 100% reliability for any application which needs to compare a
> >
Hi!
> > > High probability is all you have. Cosmic radiation hitting your
> > > computer will more likly cause problems, than colliding 64bit inode
> > > numbers ;)
> >
> > Some of us have machines designed to cope with cosmic rays, and would be
> > unimpressed with a decrease in reliability.
>
On Tue 2007-01-02 16:18:40, Kent Overstreet wrote:
> >> Any details?
> >
> >Well, one path I tried I couldn't help but post a blog
> >entry about
> >for my friends. I'm not sure it's the direction I'll
> >take with linux-
> >kernel, but the fundamentals are there: the api should
> >be the
> >s
Hi!
> >Sure it is. Numerous popular POSIX filesystems do that. There is a lot of
> >inode number space in 64 bit (of course it is a matter of time for it to
> >jump to 128 bit and more)
>
> If the filesystem was designed by someone not from Unix world (FAT, SMB,
> ...), then not. And users still
Hi!
> > > > > the use of a good hash function. The chance of an accidental
> > > > > collision is infinitesimally small. For a set of
> > > > >
> > > > > 100 files: 0.03%
> > > > >1,000,000 files: 0.03%
> > > >
> > > > I do not think we want to play with probabili
Hi!
> > > the use of a good hash function. The chance of an accidental
> > > collision is infinitesimally small. For a set of
> > >
> > > 100 files: 0.03%
> > >1,000,000 files: 0.03%
> >
> > I do not think we want to play with probability like this. I mean...
> >
Hi!
> > >> It seems like the posix idea of unique doesn't
> > >> hold water for modern file systems
> > >
> > > are you really sure?
> >
> > Well Jan's example was of Coda that uses 128-bit internal file ids.
> >
> > > and if so, why don't we fix *THAT* instead
> >
> > Hmm, sometimes you can
Hi!
> >>If user (or script) doesn't specify that flag, it
> >>doesn't help. I think
> >>the best solution for these filesystems would be
> >>either to add new syscall
> >>int is_hardlink(char *filename1, char *filename2)
> >>(but I know adding syscall bloat may be objectionable)
> >
> >it's
Hi!
> - read-only mount
> - "specatator" mount (like ro but no journal allocated for the mount,
> no fencing needed for failed node that was mounted as specatator)
I'd call it "real-read-only", and yes, that's very usefull
mount. Could we get it for ext3, too?
Hi!
> >>enums in C are (de?)promoted to integral types under most conditions, so
> >>the type-checking is useless.
> >
> >
> >It's a warning in gcc afaik and spare should complain as well.
>
> Check again.
Check sparse with -Wbitwise and enum properly marked as bitwise...
Hi!
> > > The transaction(2) syscall can be just as easily abused as ioctl(2) in
> > > this respect. People can pass pointers to ill-designed structures very
> >
> > Right. Moreover, it's not needed. The same functionality can be
> > trivially implemented by write() and read(). As the matter of
Hi!
> So I guess things have already been a bit messy in this
> area for many years, even before linux even existed, and
> in some cases you can't really do anything about it because
> the behaviour is mandated by the applicable standards, like
> POSIX, SUS, or whatever.
> (The blocking of the op
Hi!
> > Now that I'm awake and refreshed, yeah, that's awful. But
> > echo "hot-add,slot=5,device=/dev/sda" >/dev/md0/control *is* sane. Heck,
> > the system can even send back result codes that way.
>
> Only to an English speaker. I suspect Quebec City canadians would prefer a
> different com
Hi!
> Yes, and that is exactly the difference between having a side effect
> on the open(2), versus having the effect as a result of a write(2).
>
> Unfortunately, there are already some cases where an open
> on a device can have unexpected results. If you don't want
> to get blocked waiting fo
Hi!
> I have started a new virtual filesystem project, Translation Filesystem
> at
> http://trfs.sourceforge.net/ Description of the project is given below.
>
> It's still at a concept stage. If someone has any ideas about any useful
> translators that fit in this framework please write to me.
Hi!
> I have started a new virtual filesystem project, Translation Filesystem
> at
> http://trfs.sourceforge.net/ Description of the project is given below.
>
> It's still at a concept stage. If someone has any ideas about any useful
> translators that fit in this framework please write to me.
Hi!
> The patch I sent fully implements O_SYNC (actually, it implements
> O_DSYNC, which is allowed to skip the inode sync if the only attribute
> which has changed is the timestamps) and fdatasync. It's easy for me
> to make the DSYNC selectable via sysctl for full SU compliance, and I
> know o
82 matches
Mail list logo
