Re: [patch 1/2] [RFC] Simple tamper-proof device filesystem.

[David Newall]

Tetsuo Handa wrote:

If Bob is malicious and creates /dev/sda1 with block-8-2 attribute [...]


Bob can't do that.  Only root can.
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [patch 1/2] [RFC] Simple tamper-proof device filesystem.

[David Newall]

Tetsuo Handa wrote:

I meant that "/dev must be mounted for read-write mode"
  

Again, why?



You won't be able to login to the system because /sbin/mingetty
fails to "chown/chmod" /dev/tty* if /dev is mounted for read-only mode.
  


Good point.  So, if only root can modify files in /dev, what's the 
problem you're fixing?  (I'm sure you tried to explain this in your 
original post, but your reasons weren't clear to me.)

-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [patch 1/2] [RFC] Simple tamper-proof device filesystem.

[David Newall]

Tetsuo Handa wrote:

David Newall wrote:
  

Tetsuo Handa wrote:


 /dev needs to be writable, but this means that files on /dev might be
 tampered with.
  
I infer that you mean /dev needs to be writable by anyone, not by just 
its owner or owner and group (conventionally root/root.)  This goes 
against conventional wisdom, which is that /dev must be writable only by 
the administrator.  Why do you say otherwise?


I didn't mean that "/dev is writable by everybody".
  


Glad to hear it! :)


I meant that "/dev must be mounted for read-write mode"
  


Again, why?
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [patch 1/2] [RFC] Simple tamper-proof device filesystem.

[David Newall]

Tetsuo Handa wrote:

 /dev needs to be writable, but this means that files on /dev might be
 tampered with.


I infer that you mean /dev needs to be writable by anyone, not by just 
its owner or owner and group (conventionally root/root.)  This goes 
against conventional wisdom, which is that /dev must be writable only by 
the administrator.  Why do you say otherwise?

-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC PATCH 0/5] Shadow directories

[David Newall]

Al Viro wrote:

On Fri, Oct 19, 2007 at 06:07:45AM +0930, David Newall wrote:
  
considerations of this whole scheme. Linux, like most Unix systems, 
has never allowed hard links to directories for a number of reasons;
  
The claim is wrong.  UNIX systems have traditionally allowed the 
superuser to create hard links to directories.  See link(2) for 2.10BSD 
<http://www.freebsd.org/cgi/man.cgi?query=link&sektion=2&manpath=2.10+BSD>. 
Having got that wrong throws doubt on the argument; perhaps a path can 
simultaneously be a file and a directory.



Learn to read.  Linux has never allowed that.  Most of the Unix systems
do not allow that.


I did read the claim and it is ambiguous, in that it can reasonably be 
read to mean that most UNIX systems never allowed such links, which is 
wrong.  All UNIX systems allowed it until relatively recently.

-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC PATCH 0/5] Shadow directories

[David Newall]

Jaroslav Sykora wrote:

If anybody can think of any other solution of the "redirector problem", possibly
even non-kernel based one, let me know and I'd be glad :-)


If I understand your problem, you wish to treat an archive file as if it 
was a directory.  Thus, in the ideal situation, you could do the following:


cat hello.zip/hello.c
gcc hello.zip/hello.c -o hello
etc..


Rather than complicate matters with a second tree, use FUSE with an 
explicit directory.  For example, ~/expand could be your shadow, thus to 
compile hello.c from ~/hello.zip:


gcc ~/expand/hello.zip^/hello.c -o hello


I think no kernel change would be required.

I'm not keen on the caret.  One of the early claims made in 
http://lwn.net/Articles/100148/ is:
Another branch, led by Al Viro, worries about the locking 
considerations of this whole scheme. Linux, like most Unix systems, 
has never allowed hard links to directories for a number of reasons;


The claim is wrong.  UNIX systems have traditionally allowed the 
superuser to create hard links to directories.  See link(2) for 2.10BSD 
.  
Having got that wrong throws doubt on the argument; perhaps a path can 
simultaneously be a file and a directory.

-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC PATCH 0/5] Shadow directories

[David Newall]

David Newall wrote:

David Newall wrote:

Jaroslav Sykora wrote:
Let's say we have an archive file "hello.zip" with a hello world 
program source

code. We want to do this:
cat hello.zip^/hello.c
gcc hello.zip^/hello.c -o hello
etc..
  


Wouldn't you do this as a user space filesystem?

Which is what you were saying.

*SMACK* I so stupid.


On third thoughts, what's the reason for this?
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC PATCH 0/5] Shadow directories

[David Newall]

David Newall wrote:

Jaroslav Sykora wrote:
Let's say we have an archive file "hello.zip" with a hello world 
program source

code. We want to do this:
cat hello.zip^/hello.c
gcc hello.zip^/hello.c -o hello
etc..
  


Wouldn't you do this as a user space filesystem?

Which is what you were saying.

*SMACK* I so stupid.
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: [RFC PATCH 0/5] Shadow directories

[David Newall]

Jaroslav Sykora wrote:

Let's say we have an archive file "hello.zip" with a hello world program source
code. We want to do this:
cat hello.zip^/hello.c
gcc hello.zip^/hello.c -o hello
etc..
  


Wouldn't you do this as a user space filesystem?
-
To unsubscribe from this list: send the line "unsubscribe linux-fsdevel" in
the body of a message to [EMAIL PROTECTED]
More majordomo info at  http://vger.kernel.org/majordomo-info.html