All of lore.kernel.org
 help / color / mirror / Atom feed
From: "arnaud.mouiche@gmail.com" <arnaud.mouiche@gmail.com>
To: Karel Zak <kzak@redhat.com>
Cc: util-linux@vger.kernel.org, Arnaud Mouiche <arnaud.mouiche@invoxia.com>
Subject: Re: [PATCH] mkfs.cramfs: fix potential uid, gid or mode drop.
Date: Mon, 23 Jun 2014 15:26:09 +0200	[thread overview]
Message-ID: <53A82AF1.3080905@gmail.com> (raw)
In-Reply-To: <20140623111619.GJ25885@x2.net.home>

Le 23/06/2014 13:16, Karel Zak a écrit :
> On Tue, Jun 17, 2014 at 10:16:54PM +0200, arnaud.mouiche@gmail.com wrote:
>> From: Arnaud Mouiche <arnaud.mouiche@invoxia.com>
>>
>> find_identical_file() may squash files with identical contents, but
>> different uid/gid or mode.
>>
>> here is a test script to show the problem (to run as root):
>> without this patch, the output is
>>
>>    -rw-r--r-- 1 root root 4 janv.  1  1970 a
>>    -rw-r--r-- 1 root root 4 janv.  1  1970 b
>>    -rw-r--r-- 1 root root 4 janv.  1  1970 c
>>
>> whereas the expected result should be
>>
>>    -rw-r--r-- 1 root   root 4 janv.  1  1970 a
>>    -rw------- 1 root   root 4 janv.  1  1970 b
>>    -rw-r--r-- 1 daemon root 4 janv.  1  1970 c
>   Strange.
>
>> -	if (orig->size == new->size && orig->path) {
>> +	if (orig->size == new->size &&
>> +		orig->uid == new->uid &&
>> +		orig->gid == new->gid &&
>> +		orig->mode == new->mode &&
>> +		orig->path) {
>>   		if (!orig->flags)
>>   			mdfile(orig);
>>   		if (!new->flags)
>   I don't think this is right solution. The content de-duplication code
>   has to be independent on file name, uid/gid and mode. The
>   de-duplication does not mean that info about the file has been
>   removed from the cramfs image.
>   
>   The filesystem still contains file specific inode. So if you see a
>   different filename then you have to see a different uid/gid too.
>   (I guess.)
>
>
>      Karel
You are right,
The issue is in the linux kernel code indeed (fs/cramfs/inode.c)
on line 37
     /* These two macros may change in future, to provide better st_ino
        semantics. */
     #define CRAMINO(x)    (((x)->offset && (x)->size)?(x)->offset<<2:1)
     #define OFFSET(x)    ((x)->i_ino)


for linux, the inode of an entry is equal to the data offset.
2 files which have been squashed through the "eliminate_doubles" process 
(mkfs.cramfs) have identical inode number under linux,
whatever the mode, uid or gid is.

so forget about my patch, I need for find a patch for the FS mainling list

Arnaud
>

      reply	other threads:[~2014-06-23 13:26 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-06-17 20:16 [PATCH] mkfs.cramfs: fix potential uid, gid or mode drop arnaud.mouiche
2014-06-23 11:16 ` Karel Zak
2014-06-23 13:26   ` arnaud.mouiche [this message]

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=53A82AF1.3080905@gmail.com \
    --to=arnaud.mouiche@gmail.com \
    --cc=arnaud.mouiche@invoxia.com \
    --cc=kzak@redhat.com \
    --cc=util-linux@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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.