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,
since
On Fri, May 25, 2007 at 10:22:06PM +1000, [EMAIL PROTECTED] wrote:
Cc: [EMAIL PROTECTED]
Cc: Linux Filesystems linux-fsdevel@vger.kernel.org
Signed-off-by: Nick Piggin [EMAIL PROTECTED]
Applied, thanks.
--
Russell King
Linux kernel2.6 ARM Linux - http://www.arm.linux.org.uk/
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
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 other
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[0] for
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, what
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/gzip
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. Well great, we
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.
TOMOYO
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 totally
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 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
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).
-
--- 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] convention,
Sounds
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
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?
Oops. Yes.
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
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
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 linux-fsdevel@vger.kernel.org
Signed-off-by: Nick Piggin [EMAIL PROTECTED]
Applied, thanks.
Note that it won't
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 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 one
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.
22 matches
Mail list logo
