linux-ext4 - Re: Multiple Data Stream

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <20080728201506.GM9378@mit.edu>
Date:	Mon, 28 Jul 2008 16:15:07 -0400
From:	Theodore Tso <tytso@....edu>
To:	SandeepKsinha <sandeepksinha@...il.com>
Cc:	linux-ext4@...r.kernel.org
Subject: Re: Multiple Data Stream

On Mon, Jul 28, 2008 at 12:30:23PM -0700, SandeepKsinha wrote:
> 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.

You've explained *how* to do it, but not *why* it would be a good
idea.  I'm aware that it's not that difficult to do.  But it becomes a
mess for system administrators.  Most backup tools won't know how to
deal with alternate data streams, so they won't be backed up
correctly.  rsync, ftp, zip, scp, etc., all don't deal with alternate
data streams, so the potential for data loss is limitless.  

> 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.

Yes, I'm aware that this is how Solaris 9 implemented alternate data
streams.  For a good time, assuming that /var/tmp/demo_file is a file
that contains alternate data forks owned by an unprivileged user, try
this command as that unprivileged user: "runat /var/tmp/demo_file chmod 0 ."

Now try to get access to the alternate data forks; there is no way to
recover without root access.   Lovely, eh?

						- Ted
--
To unsubscribe from this list: send the line "unsubscribe linux-ext4" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html