headers
Timo Teras | 1 May 2012 11:00
Picon
Picon
Favicon

unzip fails extraction to vfat

Hi,

It seems that unzip is extra obsessive about mkdir permission errors as
it prevents extraction to vfat where it is not be possible to set all
bits.

Seems that archival/unzip.c:unzip_main() calls bb_make_directory() with
dir_mode to create the final directory component. bb_make_directory()
considers it fatal if chmod() fails. The real unzip command however,
treats this only as a warning situation.

Could we handle this situation the same in busybox? This would make it
simpler to extract files to vfat and other filesystems with limited
permissions support.

Thanks,
 Timo
Permalink | Reply | 0 comments |
headers
Rob Landley | 2 May 2012 17:10

Re: Nice kconfig hack

On 04/26/2012 08:03 AM, Lauri Kasanen wrote:
> Hi
> 
> Linus asked for a better way to handle the kconfig values:
> https://plus.google.com/102150693225130002912/posts/9gntjh57dXt
> 
> The solution is rather neat, maybe it could save generating a few
> thousand included lines in busybox too:
> 
> #define is_set(macro) is_set_(macro)
> #define macrotest_1 ,
> #define is_set_(value) is_set__(macrotest_##value)
> #define is_set__(comma) is_set___(comma 1, 0)
> #define is_set___(_, v, ...) v

It's clever, but there's a problem:

Right now, if you leave in a test for a symbol that's been removed, or
if you typo a symbol name, the build will break. And this is good, it
shows you what needs fixing.

With this new mechanism, testing for a symbol that _can't_ ever be set
means there's dead code in the source which the compiler won't warn you
about.

*shrug*  Maybe it's still worth doing, not my call...

Rob
--

-- 
GNU/Linux isn't: Linux=GPLv2, GNU=GPLv3+, they can't share code.
(Continue reading)

Permalink | Reply | 3 comments |
headers
Rich Felker | 2 May 2012 17:27

Re: Nice kconfig hack

On Wed, May 02, 2012 at 10:10:43AM -0500, Rob Landley wrote:
> On 04/26/2012 08:03 AM, Lauri Kasanen wrote:
> > Hi
> > 
> > Linus asked for a better way to handle the kconfig values:
> > https://plus.google.com/102150693225130002912/posts/9gntjh57dXt
> > 
> > The solution is rather neat, maybe it could save generating a few
> > thousand included lines in busybox too:
> > 
> > #define is_set(macro) is_set_(macro)
> > #define macrotest_1 ,
> > #define is_set_(value) is_set__(macrotest_##value)
> > #define is_set__(comma) is_set___(comma 1, 0)
> > #define is_set___(_, v, ...) v
> 
> It's clever, but there's a problem:
> 
> Right now, if you leave in a test for a symbol that's been removed, or
> if you typo a symbol name, the build will break. And this is good, it
> shows you what needs fixing.
> 
> With this new mechanism, testing for a symbol that _can't_ ever be set
> means there's dead code in the source which the compiler won't warn you
> about.
> 
> *shrug*  Maybe it's still worth doing, not my call...

I would just institute a policy of "grep -r" whenever a test symbol is
removed... That's a lot cheaper than maintaining busybox's current
(Continue reading)

Permalink | Reply | 2 comments |
headers
Rob Landley | 2 May 2012 17:44

Re: Nice kconfig hack

On 05/02/2012 10:27 AM, Rich Felker wrote:
> On Wed, May 02, 2012 at 10:10:43AM -0500, Rob Landley wrote:
>> On 04/26/2012 08:03 AM, Lauri Kasanen wrote:
>>> Hi
>>>
>>> Linus asked for a better way to handle the kconfig values:
>>> https://plus.google.com/102150693225130002912/posts/9gntjh57dXt
>>>
>>> The solution is rather neat, maybe it could save generating a few
>>> thousand included lines in busybox too:
>>>
>>> #define is_set(macro) is_set_(macro)
>>> #define macrotest_1 ,
>>> #define is_set_(value) is_set__(macrotest_##value)
>>> #define is_set__(comma) is_set___(comma 1, 0)
>>> #define is_set___(_, v, ...) v
>>
>> It's clever, but there's a problem:
>>
>> Right now, if you leave in a test for a symbol that's been removed, or
>> if you typo a symbol name, the build will break. And this is good, it
>> shows you what needs fixing.
>>
>> With this new mechanism, testing for a symbol that _can't_ ever be set
>> means there's dead code in the source which the compiler won't warn you
>> about.
>>
>> *shrug*  Maybe it's still worth doing, not my call...
> 
> I would just institute a policy of "grep -r" whenever a test symbol is
(Continue reading)

Permalink | Reply | 1 comment |
headers
Sergey Naumov | 2 May 2012 18:21
Picon

Re: switch_root and mount move

I have implemented a patch which adds -m option to switch_root which
prevents it from making a mount-move.
I haven't noticed any changes in behavior of my system, but now I can
do all necessary mounts in initramfs,
then call rsbac_init as last but one statement (after that any mount
call for root device would fail) and then call
switch_root -m /newroot /sbin/init. So I have a chroot behavior, but
also can benefit from switch_root's cleaning of initramfs content.

> It sounds like you're saying you _don't_ want to let people do "mount
> --remount,rw /", that with the current switch_root you can and with your
> proposed modification you can't?

Without -m option I would be reluctant to defer rsbac initialization
to later boot stages and it is not so good in terms of security, I
think.
If anybody interested in, I can send this patch.

Sergey Naumov.
Permalink | Reply | 8 comments |
headers
Rob Landley | 2 May 2012 17:54

Re: switch_root and mount move

On 04/25/2012 08:28 AM, Sergey Naumov wrote:
> Hello.
> 
> Could anyone explain what is the purpose of mount move in switch_root?
>>From this answer
> (http://lists.busybox.net/pipermail/busybox/2009-June/069609.html) I
> got reasons why we need to make chroot AND chdir, but can we do it
> without mount move?

The intent was to line up the system view of the mount tree with
reality, but these days chroot() itself does some of that adjustment (it
didn't used to).

I remember testing various corner cases of this and that was needed to
get the right behavior out of _something_, but it was more than 5 years
ago. If you don't need it, you don't need it.

A quick glance at the util-linux switch root implementation shows that
they're doing the mount(MS_MOVE) too, but they could easily have copied
that from me. :)

(Am I allowed to track down the github developers who implemented some
horrible java animation for switching pages and play Weird Al's
"bohemian polka" at them in a loop until they promise to yank it out and
never do it again?  *shudder*)

> My problem is that I want to disable ability to remount root to rw by
> rsbac, but I need to call rsbac_init in initramfs after all necessary
> mounts are done, so at the time switch_root is called
> mounting/remounting of root device is prohibited. Simple chroot works,
(Continue reading)

Permalink | Reply | 9 comments |
headers
Rob Landley | 2 May 2012 19:01

Re: switch_root and mount move

On 05/02/2012 11:21 AM, Sergey Naumov wrote:
> I have implemented a patch which adds -m option to switch_root which
> prevents it from making a mount-move.

If the mount move isn't needed, it shouldn't do it. If it is needed, it
should do it. Providing a knob to control something 99.9% of the
userbase have no idea even _exists_ seems less than ideal.

> I haven't noticed any changes in behavior of my system, but now I can
> do all necessary mounts in initramfs,

So you haven't noticed any changes in behavior, except for this change
in behavior...

I'm still unclear on what you're trying to do.

> then call rsbac_init as last but one statement (after that any mount
> call for root device would fail) and then call
> switch_root -m /newroot /sbin/init. So I have a chroot behavior, but
> also can benefit from switch_root's cleaning of initramfs content.

So you do something funky to make your filesystem immuntable, and this
prevents a mount --move from working on it.

Which is really weird because mount --move is a vfs option, not a
filesystem option.

>> It sounds like you're saying you _don't_ want to let people do "mount
>> --remount,rw /", that with the current switch_root you can and with your
>> proposed modification you can't?
(Continue reading)

Permalink | Reply | 7 comments |
headers
Rob Landley | 2 May 2012 19:25

Re: switch_root and mount move

On 05/02/2012 12:06 PM, Cathey, Jim wrote:
> 
>   mkdir("sub", 0700);
>   chroot("sub");
>   chdir("../../../../../../../../..");
>   chroot(".");
> 
> If that works, the kernel is broken IMHO.
> Or is this predicated on the CWD not being
> somewhere in the chroot path to begin with?
> 
> -- Jim

Yes, chroot is broken. If you're root, you can break out of a chroot.

  http://landley.net/notes-2011.html#02-06-2011

I've had a todo item to fix this for most of a year now, but it's a
couple weeks work and competes with 800 other todo items...

Rob
--

-- 
GNU/Linux isn't: Linux=GPLv2, GNU=GPLv3+, they can't share code.
Either it's "mere aggregation", or a license violation.  Pick one.
Permalink | Reply | 2 comments |
headers
Cathey, Jim | 2 May 2012 19:06

RE: switch_root and mount move


  mkdir("sub", 0700);
  chroot("sub");
  chdir("../../../../../../../../..");
  chroot(".");

If that works, the kernel is broken IMHO.
Or is this predicated on the CWD not being
somewhere in the chroot path to begin with?

-- Jim
Permalink | Reply | 3 comments |
headers
Sergey Naumov | 2 May 2012 20:06
Picon

Re: switch_root and mount move

> Oh dear, "security".

> You're aware you can break out of a simple chroot and get back into the
> initramfs, right?

As I understood from your own description in switch_root.c, you are
calling chdir("/") to prevent such an ability.
Can an attacker break out from this chroot (applet called from bash,
not a chroot() system call in a C program)?

> I'm still unclear on what you're trying to do.
I am trying to call rsbac_init in initramfs (so as soon as possible)
with acl set up for /dev/sda2 (my root device) which prohibits its
mounting/remounting (the only way to disable remount in rsbac is to
disable mount), but as long as original switch_root (which has to be
the last statement in initramfs ) is using mount() call on root to
move it from /newroot to /, initialized rsbac prohibits this call and
it leads to a kernel panic (It is strange for me too that rsbac treats
mount with MOVE flag like regular mount).
I can use chroot applet, but also I want to clean initramfs content,
so with -m option switch_root cleans initramfs and then performs the
same thing as chroot applet (chroot(newroot); chdir("/")), but does it
"atomically".

> So you haven't noticed any changes in behavior, except for this change
> in behavior...
I wanted to say that my system remains operable, but with additional
25Mb of free memory.
The only thing I haven't tested is a necessity of mount -o move /proc
/newroot/proc && mount -o move /sys /newroot/sys calls which I have
(Continue reading)

Permalink | Reply | 1 comment |

Gmane