Trond Myklebust [EMAIL PROTECTED] wrote:
On Mon, 2008-01-28 at 05:38 +0100, Andi Kleen wrote:
On Monday 28 January 2008 05:13:09 Trond Myklebust wrote:
On Mon, 2008-01-28 at 03:58 +0100, Andi Kleen wrote:
The problem is that it's not a race in who gets to do its thing first,
but a
+++ linux/fs/fcntl.c
@@ -240,11 +240,15 @@ static int setfl(int fd, struct file * f
lock_kernel();
if ((arg ^ filp-f_flags) FASYNC) {
- if (filp-f_op filp-f_op-fasync) {
+ if (filp-f_op filp-f_op-unlocked_fasync)
+
On Fri, 25 Jan 2008, Bryan Henderson wrote:
AIX basically did this with SIGDANGER (the signal is ignored by
default), except there wasn't the ability for the process to tell the
kernel at what level of memory pressure before it should start getting
notified, and there was no way for the
Alan Cox [EMAIL PROTECTED] wrote:
I'd tried to advocate SIGDANGER some years ago as well, but none of
the kernel maintainers were interested. It definitely makes sense
to have some sort of mechanism like this. At the time I first brought
it up it was in conjunction with Netscape using too
Al Boldi [EMAIL PROTECTED] wrote:
Even after a black-out shutdown, the corruption is pretty minimal, using
ext3fs at least. So let's take advantage of this fact and do an optimistic
fsck, to assure integrity per-dir, and assume no external corruption. Then
we release this checked dir to the
On Thu, 5 Jul 2007, DervishD wrote:
* Bodo Eggert [EMAIL PROTECTED] dixit:
Standardisation is good, but autotools (as they are used) usurally isn't.
Usually, by picking other's project configure.in and tweak blindly.
If it were that easy to write a correct automake script, people
alan [EMAIL PROTECTED] wrote:
I just wish that people would learn from the mistakes of others. The
MacOS is a prime example of why you do not want to use a forked
filesystem, yet some people still seem to think it is a good idea.
(Forked filesystems tend to be fragile and do not play well
Pavel Machek [EMAIL PROTECTED] wrote:
Another idea is to export the filesystem internal ID as an arbitray
length cookie through the extended attribute interface. That could be
stored/compared by the filesystem quite efficiently.
How will that work for FAT?
Or maybe we can relax that
Mike Waychison [EMAIL PROTECTED] wrote:
Consider the following pseudo example:
main():
chdir(/);
fd = open(., O_RDONLY);
clone(cloned_func, cloned_stack, CLONE_NEWNS, NULL);
cloned_func:
fchdir(fd);
chdir(..);
if main is run within a chroot where it's / is on the same vfsmount as
On Tue, 19 Apr 2005, Eric Van Hensbergen wrote:
On 4/17/05, Bodo Eggert [EMAIL PROTECTED]
I was thinking about this a while back and thought having a user-mount
permissions file might be the right way to address lots of these
issues. Essentially it would contain information about what
On Tue, 19 Apr 2005, Eric Van Hensbergen wrote:
On 4/19/05, Bodo Eggert [EMAIL PROTECTED] wrote:
Allowing user mounts with no* should be allways ok (no config needed
besides the ulimit), and mounting specified files to defined locations
is allready supported by fstab.
Do folks think
Eric Van Hensbergen [EMAIL PROTECTED] wrote:
On 4/11/05, Miklos Szeredi [EMAIL PROTECTED] wrote:
1) Only allow mount over a directory for which the user has write
access (and is not sticky)
2) Use nosuid,nodev mount options
[...]
Do these solve all the security concerns with
Jamie Lokier [EMAIL PROTECTED] wrote:
Miklos Szeredi wrote:
4) Access should not be further restricted for the owner of the
mount, even if permission bits, uid or gid would suggest
otherwise
Why? Surely you want to prevent writing to files which don't have the
writable bit
On Tue, 12 Apr 2005, Jamie Lokier wrote:
Bodo Eggert [EMAIL PROTECTED] wrote:
I think that would be _much_ nicer implemented as a mount which is
invisible to other users, rather than one which causes the admin's
scripts to spew error messages. Is the namespace mechanism at all
14 matches
Mail list logo
