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