All of lore.kernel.org
 help / color / mirror / Atom feed
* output file cannot be in the UBIFS root directory check is not working quite well
@ 2012-10-03 19:30 kyak
  2012-10-05 15:57 ` kyak
  0 siblings, 1 reply; 8+ messages in thread
From: kyak @ 2012-10-03 19:30 UTC (permalink / raw)
  To: linux-mtd

Hi,

Consider the following sequence of commands:

cd ~
mkdir -p /tmp/wtf/wtf1
chmod u-r /tmp/wtf
mkfs.ubifs -m 4096 -e 516096 -c 4095 -d /tmp/wtf/wtf1 -o mytest.img
Error: output file cannot be in the UBIFS root directory

mytest.img is not inside /tmp/wtf/wtf1, but mkfs.ubifs fails because 
/tmp/wtf is not readable.
It seems that implementation of in_path(..) in mkfs.ubifs.c is not quite 
correct to handle this type of situations.

If you are wondering, my /home is not readable, and this prevents me from 
building any ubifs image inside of /home/user.

Thanks in advance.

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: output file cannot be in the UBIFS root directory check is not working quite well
  2012-10-03 19:30 output file cannot be in the UBIFS root directory check is not working quite well kyak
@ 2012-10-05 15:57 ` kyak
  2012-10-08 13:57   ` Ricard Wanderlof
  0 siblings, 1 reply; 8+ messages in thread
From: kyak @ 2012-10-05 15:57 UTC (permalink / raw)
  To: linux-mtd

I think the fact that i created that example directories in /tmp is 
misleading. 
This is not a tmpfs problem.

I observe the same problem with any other directory (namely, with my 
/home, which is not reabable).

When one of the directories in "-d" hierarchy is not readable, mkfs.ubifs 
will fail all the time, thinking that the output file is located in UBIFS 
root directory.

On Wed, 3 Oct 2012, kyak wrote:

> Hi,
>
> Consider the following sequence of commands:
>
> cd ~
> mkdir -p /tmp/wtf/wtf1
> chmod u-r /tmp/wtf
> mkfs.ubifs -m 4096 -e 516096 -c 4095 -d /tmp/wtf/wtf1 -o mytest.img
> Error: output file cannot be in the UBIFS root directory
>
> mytest.img is not inside /tmp/wtf/wtf1, but mkfs.ubifs fails because /tmp/wtf 
> is not readable.
> It seems that implementation of in_path(..) in mkfs.ubifs.c is not quite 
> correct to handle this type of situations.
>
> If you are wondering, my /home is not readable, and this prevents me from 
> building any ubifs image inside of /home/user.
>
> Thanks in advance.
>

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: output file cannot be in the UBIFS root directory check is not working quite well
  2012-10-05 15:57 ` kyak
@ 2012-10-08 13:57   ` Ricard Wanderlof
  2012-10-08 14:40     ` kyak
  0 siblings, 1 reply; 8+ messages in thread
From: Ricard Wanderlof @ 2012-10-08 13:57 UTC (permalink / raw)
  To: kyak; +Cc: linux-mtd


On Fri, 5 Oct 2012, kyak wrote:

> I observe the same problem with any other directory (namely, with my
> /home, which is not reabable).
>
> When one of the directories in "-d" hierarchy is not readable, 
> mkfs.ubifs will fail all the time, thinking that the output file is 
> located in UBIFS root directory.

I can agree with you that the error message looks wrong for this case, but 
what is the point of attempting to create a file system image from a 
directory tree which is not readable?

/Ricard

>
> On Wed, 3 Oct 2012, kyak wrote:
>
>> Hi,
>>
>> Consider the following sequence of commands:
>>
>> cd ~
>> mkdir -p /tmp/wtf/wtf1
>> chmod u-r /tmp/wtf
>> mkfs.ubifs -m 4096 -e 516096 -c 4095 -d /tmp/wtf/wtf1 -o mytest.img
>> Error: output file cannot be in the UBIFS root directory
>>
>> mytest.img is not inside /tmp/wtf/wtf1, but mkfs.ubifs fails because /tmp/wtf
>> is not readable.
>> It seems that implementation of in_path(..) in mkfs.ubifs.c is not quite
>> correct to handle this type of situations.
>>
>> If you are wondering, my /home is not readable, and this prevents me from
>> building any ubifs image inside of /home/user.
>>
>> Thanks in advance.
>>
>
> ______________________________________________________
> Linux MTD discussion mailing list
> http://lists.infradead.org/mailman/listinfo/linux-mtd/
>

-- 
Ricard Wolf Wanderlöf                           ricardw(at)axis.com
Axis Communications AB, Lund, Sweden            www.axis.com
Phone +46 46 272 2016                           Fax +46 46 13 61 30

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: output file cannot be in the UBIFS root directory check is not working quite well
  2012-10-08 13:57   ` Ricard Wanderlof
@ 2012-10-08 14:40     ` kyak
  2012-10-08 14:53       ` Ricard Wanderlof
  0 siblings, 1 reply; 8+ messages in thread
From: kyak @ 2012-10-08 14:40 UTC (permalink / raw)
  To: Ricard Wanderlof; +Cc: linux-mtd

[-- Attachment #1: Type: TEXT/PLAIN, Size: 2061 bytes --]

If a directory is not readable it only means that you can't list its 
contents. But it doesn't mean that you can't list contents of directories 
below that directory.

Once again, here is a simple (my) use case. My /home is not readable (i 
can't list its contents), and this prevents me from building any ubifs 
image inside of /home/user (which is readable).

I really hope i made myself clear this time.

On Mon, 8 Oct 2012, Ricard Wanderlof wrote:

>
> On Fri, 5 Oct 2012, kyak wrote:
>
>> I observe the same problem with any other directory (namely, with my
>> /home, which is not reabable).
>> 
>> When one of the directories in "-d" hierarchy is not readable, mkfs.ubifs 
>> will fail all the time, thinking that the output file is located in UBIFS 
>> root directory.
>
> I can agree with you that the error message looks wrong for this case, but 
> what is the point of attempting to create a file system image from a 
> directory tree which is not readable?
>
> /Ricard
>
>> 
>> On Wed, 3 Oct 2012, kyak wrote:
>> 
>>> Hi,
>>> 
>>> Consider the following sequence of commands:
>>> 
>>> cd ~
>>> mkdir -p /tmp/wtf/wtf1
>>> chmod u-r /tmp/wtf
>>> mkfs.ubifs -m 4096 -e 516096 -c 4095 -d /tmp/wtf/wtf1 -o mytest.img
>>> Error: output file cannot be in the UBIFS root directory
>>> 
>>> mytest.img is not inside /tmp/wtf/wtf1, but mkfs.ubifs fails because 
>>> /tmp/wtf
>>> is not readable.
>>> It seems that implementation of in_path(..) in mkfs.ubifs.c is not quite
>>> correct to handle this type of situations.
>>> 
>>> If you are wondering, my /home is not readable, and this prevents me from
>>> building any ubifs image inside of /home/user.
>>> 
>>> Thanks in advance.
>>> 
>> 
>> ______________________________________________________
>> Linux MTD discussion mailing list
>> http://lists.infradead.org/mailman/listinfo/linux-mtd/
>> 
>
> -- 
> Ricard Wolf Wanderlöf                           ricardw(at)axis.com
> Axis Communications AB, Lund, Sweden            www.axis.com
> Phone +46 46 272 2016                           Fax +46 46 13 61 30
>

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: output file cannot be in the UBIFS root directory check is not working quite well
  2012-10-08 14:40     ` kyak
@ 2012-10-08 14:53       ` Ricard Wanderlof
  2012-10-08 15:13         ` kyak
  0 siblings, 1 reply; 8+ messages in thread
From: Ricard Wanderlof @ 2012-10-08 14:53 UTC (permalink / raw)
  To: kyak; +Cc: Linux mtd


On Mon, 8 Oct 2012, kyak wrote:

> If a directory is not readable it only means that you can't list its
> contents. But it doesn't mean that you can't list contents of directories
> below that directory.
>
> Once again, here is a simple (my) use case. My /home is not readable (i
> can't list its contents), and this prevents me from building any ubifs
> image inside of /home/user (which is readable).
>
> I really hope i made myself clear this time.

Definitely. I see your point now. This must be a definite bug in 
in_path().

One problem though is that when in_path() traverses the tree upwards, and 
encounters a directory which it can't read it can't complete its job. On 
the other hand, it shouldn't have to do that, it really only needs to see 
that the output file is not below the top level of the input tree. Or am I 
missing a case here?

/Ricard
-- 
Ricard Wolf Wanderlöf                           ricardw(at)axis.com
Axis Communications AB, Lund, Sweden            www.axis.com
Phone +46 46 272 2016                           Fax +46 46 13 61 30

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: output file cannot be in the UBIFS root directory check is not working quite well
  2012-10-08 14:53       ` Ricard Wanderlof
@ 2012-10-08 15:13         ` kyak
  2012-10-10 14:55           ` kyak
  0 siblings, 1 reply; 8+ messages in thread
From: kyak @ 2012-10-08 15:13 UTC (permalink / raw)
  To: Ricard Wanderlof; +Cc: Linux mtd

On Mon, 8 Oct 2012, Ricard Wanderlof wrote:

> Definitely. I see your point now. This must be a definite bug in in_path().
>
> One problem though is that when in_path() traverses the tree upwards, and 
> encounters a directory which it can't read it can't complete its job. On the 
> other hand, it shouldn't have to do that, it really only needs to see that 
> the output file is not below the top level of the input tree. Or am I missing 
> a case here?
>
Yes, it only needs to check if the output file is above the top level
of the input tree. But I guess it's not that easy - first things that come 
into my mind are symbolic links and mount --bind.

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: output file cannot be in the UBIFS root directory check is not working quite well
  2012-10-08 15:13         ` kyak
@ 2012-10-10 14:55           ` kyak
  2012-10-11  6:01             ` Artem Bityutskiy
  0 siblings, 1 reply; 8+ messages in thread
From: kyak @ 2012-10-10 14:55 UTC (permalink / raw)
  To: dedekind1; +Cc: Linux mtd

Thanks Artem, your patch 
(http://lists.infradead.org/pipermail/linux-mtd/2012-October/044477.html) 
has fixed my problem as well.

On Mon, 8 Oct 2012, kyak wrote:

> On Mon, 8 Oct 2012, Ricard Wanderlof wrote:
>
>> Definitely. I see your point now. This must be a definite bug in in_path().
>> 
>> One problem though is that when in_path() traverses the tree upwards, and 
>> encounters a directory which it can't read it can't complete its job. On 
>> the other hand, it shouldn't have to do that, it really only needs to see 
>> that the output file is not below the top level of the input tree. Or am I 
>> missing a case here?
>> 
> Yes, it only needs to check if the output file is above the top level
> of the input tree. But I guess it's not that easy - first things that come 
> into my mind are symbolic links and mount --bind.
>

^ permalink raw reply	[flat|nested] 8+ messages in thread

* Re: output file cannot be in the UBIFS root directory check is not working quite well
  2012-10-10 14:55           ` kyak
@ 2012-10-11  6:01             ` Artem Bityutskiy
  0 siblings, 0 replies; 8+ messages in thread
From: Artem Bityutskiy @ 2012-10-11  6:01 UTC (permalink / raw)
  To: kyak; +Cc: Linux mtd

[-- Attachment #1: Type: text/plain, Size: 782 bytes --]

On Wed, 2012-10-10 at 18:55 +0400, kyak wrote:
> Thanks Artem, your patch 
> (http://lists.infradead.org/pipermail/linux-mtd/2012-October/044477.html) 
> has fixed my problem as well.

Good!

> > Yes, it only needs to check if the output file is above the top level
> > of the input tree. But I guess it's not that easy - first things that come 
> > into my mind are symbolic links and mount --bind.

This patch should take care of symbolic links - realpath should resolve
them. WRT bind-mounts - well, I consider this an unlikely case and it is
not a big deal if we do not detect this. mkfs.ubifs will fail somewhere
else, I guess, then.

But of course, I will not object if someone improves the check and
submits a patch.

-- 
Best Regards,
Artem Bityutskiy

[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

^ permalink raw reply	[flat|nested] 8+ messages in thread

end of thread, other threads:[~2012-10-11  6:01 UTC | newest]

Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2012-10-03 19:30 output file cannot be in the UBIFS root directory check is not working quite well kyak
2012-10-05 15:57 ` kyak
2012-10-08 13:57   ` Ricard Wanderlof
2012-10-08 14:40     ` kyak
2012-10-08 14:53       ` Ricard Wanderlof
2012-10-08 15:13         ` kyak
2012-10-10 14:55           ` kyak
2012-10-11  6:01             ` Artem Bityutskiy

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.