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 swap ;-)
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 right
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 get
On Mon 2008-01-28 14:56:33, Theodore Tso wrote:
On Mon, Jan 28, 2008 at 07:30:05PM +, 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/file descriptors in lowmem, but I
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-bit counter?
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 engineered to save
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
?
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-by: Pavel Machek [EMAIL PROTECTED]
diff --git a/Documentation/filesystems/ext3.txt
b/Documentation/filesystems/ext3
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
because there
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.
After a unclean
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 unprivileged users.
This
has
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 consider 'kill
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 actually be
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 addition
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 believe
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 over
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
Hell,
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_
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
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
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 believe it
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 change the
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 phrase here is if
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 version of
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 already, see that when
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 period of time,
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
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!
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 renamed or
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 take each file
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,
but
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 lengths to
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 -- until your
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 -- until your httpd is
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 pathnames so we introduce
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?
The maximum length of a pathname
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);
...
and the
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
to actually implement.
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 logfs
Can we call it jörnfs? :)
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 testing
is a good
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,10 @@
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, license
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 means we can
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 recovery
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 nothing
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? (I.e.
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 you have dir1/a
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 cases using
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
more than a few
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
syscall interface,
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.
With the
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...
imagine 4G files,
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!
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 want to
Hi!
It seems like the posix idea of unique st_dev, st_ino 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't fix the
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 also the wrong api;
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 fact,
had
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 open on
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.
Any
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 of
64 matches
Mail list logo
