From: SandeepKsinha <sandeepksinha@gmail.com>
To: linux-ext4@vger.kernel.org
Subject: Re: Multiple Data Stream
Date: Mon, 28 Jul 2008 12:30:23 -0700 (PDT) [thread overview]
Message-ID: <18697577.post@talk.nabble.com> (raw)
In-Reply-To: <20080727230455.GE7922@mit.edu>
Theodore Tso wrote:
>
> On Sun, Jul 27, 2008 at 04:04:32PM +0530, Rohit Sharma wrote:
>> Does ext2/ext3 supports multiple data streams.
>
> No. The primary use of alternate data streams in Windows XP has been
> Virii, Trojan Horses, and Rootkits. See this article by Rick Cook,
> "Alternate Data Streams: Threat or Menace:"
>
>
> http://www.informit.com/articles/article.aspx?p=413685
>
> (Threat or Menace? Menance or Threat? Or to quote Bugs Bunny/Daffy
> Duck, "Would you like to shoot me now or wait till you get home?" :-)
>
> I've heard stories of System Administrators refusing to upgrade past
> Solaris 8 because of concerns of attackers being able to use the
> alternate data streams feature which Sun unfortunately added in
> Solaris 9 to hide rootkits in ways that traditional scanning tools
> would not be able to detect.
>
> I've yet to see a coherent argument for why multiple data streams is
> worth it....
>
>
Hey Ted,
I am a newbie into these filesystems but I can see the positive sides of
these Alternate Data Streams or multiple data streams too, needless to
mention those.
If you look a bit more deeper into it, in my perspective and the kind of
implementation I look forward to, here is what I have.
Access to the multiple data stream can be done through a file descriptor.
Applications can open the multiple data stream to get a file descriptor and
can do read(), write(), mmap().. using the file descriptor. These system
calls would work as if it is been operated on a regular file.
The multiple data streams of a file will be stored in a hidden named data
stream directory inode associated with the file. The hidden directory inode
for the file can be accessed only through the multiple data stream API.
Now, as the multiple data streams has their own associated inodes, we could
store the access permission as well as the owner/group information in the
multiple data stream inode. This way the access control for the multiple
data stream can be controlled by the permissions stored in the multiple data
stream inode.
We could have a model where we use the permissions on the parent file
to be used to check the accessibility of the alternate data stream. It would
also make great sense to me, if we just add a fall back to the kernel to
decide whether a user with particular credentials, should be allowed to
access/make changes to these multiple data streams that are associated with
the file.
To add more to it, any regular file can be created in a regular way but
whatever mechanism is used to create these multiple data streams associated
with the regular file will surely undergo a permission check by the
underlying OS or the filesystem.
Thanks & Regards,
SandeepKsinha.
>
> - Ted
>
>
> Bugs Bunny: Would you like to shoot me now or wait 'til you get home?
> Daffy Duck: Shoot him now! Shoot him now!
> Bugs Bunny: You keep outta this! He doesn't have to shoot you now!
> Daffy Duck: He does SO have to shoot me now!
> [to Elmer]
> Daffy Duck: I demand that you shoot me now!
> [Elmer raises his gun. As Daffy sticks his tongue out at Bugs, he is shot]
>
>
> Daffy Duck: Let'th run through that again.
> Bugs Bunny: Okay.
> [neutral toned]
> Bugs Bunny: Wouldja like to shoot me now or wait till ya get home.
> Daffy Duck: [neutral toned] Shoot him now, shoot him now.
> Bugs Bunny: [neutral toned] You keep outta dis, he doesn't hafta shoot you
> now.
> Daffy Duck: [with expression] HA! THAT'TH IT! HOLD IT RIGHT THERE!
> [to audience]
> Daffy Duck: Pronoun trouble.
> [to Bugs]
> Daffy Duck: It'th not "He doethn't have to shoot
> [pointing to Bugs]
> Daffy Duck: *you* now." It'th "He doethn't have to shoot
> [pointing to himself]
> Daffy Duck: *me* now."
> [with anger]
> Daffy Duck: Well, *I* thay he *does* have to shoot me now!
> [to Elmer]
> Daffy Duck: THO SHOOT ME NOW!
> [Elmer shoots him]
> --
> To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
>
--
View this message in context: http://www.nabble.com/Multiple-Data-Stream-tp18675139p18697577.html
Sent from the linux-ext4 mailing list archive at Nabble.com.
next prev parent reply other threads:[~2008-07-28 19:30 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-07-27 10:34 Multiple Data Stream Rohit Sharma
2008-07-27 23:04 ` Theodore Tso
2008-07-28 19:30 ` SandeepKsinha [this message]
2008-07-28 20:15 ` Theodore Tso
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=18697577.post@talk.nabble.com \
--to=sandeepksinha@gmail.com \
--cc=linux-ext4@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).