On May 26, 2007, at 22:37:02, [EMAIL PROTECTED] wrote:
On Sat, 26 May 2007 22:10:34 EDT, Kyle Moffett said:
On May 26, 2007, at 19:08:56, Toshiharu Harada wrote:
(1) Object labeling has a assumption that labels are always
properly defined and maintained. This can not be easily achieved.
Tha
On Sat, 26 May 2007 22:10:34 EDT, Kyle Moffett said:
> On May 26, 2007, at 19:08:56, Toshiharu Harada wrote:
> > (1) Object labeling has a assumption that labels are always
> > properly defined and maintained. This can not be easily achieved.
>
> That's a circular argument, and a fairly trivial
On Sun, May 27, 2007 at 12:55:30AM +0100, David Howells wrote:
> J. Bruce Fields <[EMAIL PROTECTED]> wrote:
>
> > > + if (!afs_lock_manager) {
> > > + afs_lock_manager = create_singlethread_workqueue("kafs_lockd");
> > > + if (!afs_lock_manager)
> > > + return -ENOM
On May 26, 2007, at 19:08:56, Toshiharu Harada wrote:
2007/5/27, James Morris <[EMAIL PROTECTED]>:
On Sat, 26 May 2007, Kyle Moffett wrote:
AppArmor). On the other hand, if you actually want to protect
the _data_, then tagging the _name_ is flawed; tag the *DATA*
instead.
Bingo.
(This is
On Sat, 26 May 2007 15:58:50 PDT, Casey Schaufler said:
> Fair enough, I don't believe that an argv[0] check ought to
> be used as a security mechanism. I am not convinced that everyone
> would agree with us.
Having seen my share of argv[0]-related security bugs in my years, I have to
agree that i
On Sat, May 26, 2007 at 10:14:04AM +0100, Russell King wrote:
> On Fri, May 25, 2007 at 10:22:06PM +1000, [EMAIL PROTECTED] wrote:
> > Cc: [EMAIL PROTECTED]
> > Cc: Linux Filesystems
> > Signed-off-by: Nick Piggin <[EMAIL PROTECTED]>
>
> Applied, thanks.
Note that it won't apply upstream yet unt
Randy Dunlap <[EMAIL PROTECTED]> wrote:
> Don't use explicit extern specifier and quieten sparse warning:
> fs/afs/vnode.c:564:12: warning: function 'afs_vnode_link' with external
> linkage has definition
Acked-By: David Howells <[EMAIL PROTECTED]>
-
To unsubscribe from this list: send the line
Kyle Moffett <[EMAIL PROTECTED]> wrote:
> I was actually under the impression that OpenAFS had support for byte-
> range locking (as well as lock upgrade/downgrade);
As far as I know, there is no support for byte-range locking at all in the AFS
protocol itself. The client can try to emulate byt
J. Bruce Fields <[EMAIL PROTECTED]> wrote:
> > + if (!afs_lock_manager) {
> > + afs_lock_manager = create_singlethread_workqueue("kafs_lockd");
> > + if (!afs_lock_manager)
> > + return -ENOMEM;
> > + }
> > + return 0;
>
> Doesn't this need some locking
2007/5/27, James Morris <[EMAIL PROTECTED]>:
On Sat, 26 May 2007, Kyle Moffett wrote:
> AppArmor). On the other hand, if you actually want to protect the _data_,
> then tagging the _name_ is flawed; tag the *DATA* instead.
Bingo.
(This is how traditional Unix DAC has always functioned, and is
--- Andreas Gruenbacher <[EMAIL PROTECTED]> wrote:
> On Friday 25 May 2007 21:06, Casey Schaufler wrote:
> > --- Jeremy Maitin-Shepard <[EMAIL PROTECTED]> wrote:
> > > ...
> > > Well, my point was exactly that App Armor doesn't (as far as I know) do
> > > anything to enforce the argv[0] conventio
From: Randy Dunlap <[EMAIL PROTECTED]>
Don't use explicit extern specifier and quieten sparse warning:
fs/afs/vnode.c:564:12: warning: function 'afs_vnode_link' with external linkage
has definition
Signed-off-by: Randy Dunlap <[EMAIL PROTECTED]>
---
fs/afs/vnode.c |2 +-
1 file changed, 1 i
On Sat, 26 May 2007, Kyle Moffett wrote:
> AppArmor). On the other hand, if you actually want to protect the _data_,
> then tagging the _name_ is flawed; tag the *DATA* instead.
Bingo.
(This is how traditional Unix DAC has always functioned, and is what
SELinux does: object labeling).
- Ja
On Fri, 25 May 2007, Crispin Cowan wrote:
> Finally, AA doesn't care what the contents of the executable are. We
> assume that it is a copy of metasploit or something, and confine it to
> access only the resources that the policy says.
As long as these resources are only files. There is no confi
On May 26, 2007, at 10:44:46, Tetsuo Handa wrote:
Andreas Gruenbacher wrote:
Tetsuo Handa wrote:
Therefore, TOMOYO Linux checks the combination of filename and
argv[0] passed to execve().
So you are indeed trying to control the value of argv[0]? Well,
good luck with that, but it's totally
On Saturday 26 May 2007 16:44, Tetsuo Handa wrote:
> Hello.
>
> Andreas Gruenbacher wrote:
> > > Therefore, TOMOYO Linux checks the combination of filename and argv[0]
> > > passed to execve().
> >
> > So you are indeed trying to control the value of argv[0]? Well, good luck
> > with that, but it's
Hello.
Andreas Gruenbacher wrote:
> > Therefore, TOMOYO Linux checks the combination of filename and argv[0]
> > passed to execve().
> So you are indeed trying to control the value of argv[0]? Well, good luck
> with
> that, but it's totally insane. You are guaranteed to break some applications.
On Saturday 26 May 2007 15:34, Alan Cox wrote:
> > As such, AA can detect whether you did exec("gzip") or exec("gunzip")
> > and apply the policy relevant to the program. It could apply different
>
> That's not actually useful for programs which link the same binary to
> multiple names because if y
On Saturday 26 May 2007 14:09, Tetsuo Handa wrote:
> Hello.
>
> Andreas Gruenbacher wrote:
> > > exec { "/usr/bin/gunzip" } "gzip", "-9", "some/file/to.gz";
> >
> > The above Perl code executes /usr/bin/gunzip and sets argv[0] to "gzip",
> > so this confirms that the value of argv[0] is arbitrary.
> As such, AA can detect whether you did exec("gzip") or exec("gunzip")
> and apply the policy relevant to the program. It could apply different
That's not actually useful for programs which link the same binary to
multiple names because if you don't consider argv[0] as well I can run
/usr/bin/gzi
On Friday 25 May 2007 21:06, Casey Schaufler wrote:
> --- Jeremy Maitin-Shepard <[EMAIL PROTECTED]> wrote:
> > ...
> > Well, my point was exactly that App Armor doesn't (as far as I know) do
> > anything to enforce the argv[0] convention,
>
> Sounds like an opportunity for improvement then.
Jeez,
Hello.
Andreas Gruenbacher wrote:
> > exec { "/usr/bin/gunzip" } "gzip", "-9", "some/file/to.gz";
> The above Perl code executes /usr/bin/gunzip and sets argv[0] to "gzip", so
> this confirms that the value of argv[0] is arbitrary. Well great, we already
> knew.
> AppArmor does not look at argv
On Saturday 26 May 2007 07:20, Kyle Moffett wrote:
> On May 24, 2007, at 14:58:41, Casey Schaufler wrote:
> > On Fedora zcat, gzip and gunzip are all links to the same file. I
> > can imagine (although it is a bit of a stretch) allowing a set of
> > users access to gunzip but not gzip (or the
Hello, Neil Brown.
Please cc me on blkdev barriers and, if you haven't yet, reading
Documentation/block/barrier.txt can be helpful too.
Neil Brown wrote:
[--snip--]
> 1/ SAFE. With a SAFE device, there is no write-behind cache, or if
> there is it is non-volatile. Once a write complet
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
On Fri, May 25, 2007 at 10:22:06PM +1000, [EMAIL PROTECTED] wrote:
> Cc: [EMAIL PROTECTED]
> Cc: Linux Filesystems
> Signed-off-by: Nick Piggin <[EMAIL PROTECTED]>
Applied, thanks.
--
Russell King
Linux kernel2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of:
-
To unsubscribe f
On Fri, May 25, 2007 at 04:35:18PM +0200, Anders Larsen wrote:
> On 2007-05-25 14:22:11, [EMAIL PROTECTED] wrote:
> > Signed-off-by: Nick Piggin <[EMAIL PROTECTED]>
>
> Acked-by: Anders Larsen <[EMAIL PROTECTED]>
>
> (although we might just as well do away with the 'write' methods completely,
>
27 matches
Mail list logo
