.inodes and .bitmap

A friend of mine pointed out how easy it was to overwrite the
…inodes and .bitmap files

cp file /.inodes and kaboum.

Shouldn’t this be “fix”

  • Mario

I tend to disagree that this is a “problem”. If you’re a superuser you
can by definition do bad things to the system. If a normal user could do
this, then this definitely would need fixing.

rick

Mario Charest wrote:

A friend of mine pointed out how easy it was to overwrite the
.inodes and .bitmap files

cp file /.inodes and kaboum.

Shouldn’t this be “fix”

  • Mario

“Rick Lake” <rwlake@SPAM.REDIRECTED.TO.DEV.NULL> wrote in message
news:3A7723A1.47166998@SPAM.REDIRECTED.TO.DEV.NULL

I tend to disagree that this is a “problem”. If you’re a superuser you
can by definition do bad things to the system. If a normal user could do
this, then this definitely would need fixing.

I agree but isn’t this a tiny bit fragile.
I don’t thing you can delete the FAT under dos with a copy command :wink:
It’s also a concern (to me at least) since most system I’v seen
have all their program running as root. Who goes to the trouble
of creating dummy user for a deeply embedded system.

But then again rm -rf /* is pretty devasting as well :wink:

rick

Mario Charest wrote:

A friend of mine pointed out how easy it was to overwrite the
.inodes and .bitmap files

cp file /.inodes and kaboum.

Shouldn’t this be “fix”

  • Mario

Mario Charest <mcharest@void_zinformatic.com> wrote:


“Rick Lake” <> rwlake@SPAM.REDIRECTED.TO.DEV.NULL> > wrote in message
news:> 3A7723A1.47166998@SPAM.REDIRECTED.TO.DEV.NULL> …
I tend to disagree that this is a “problem”. If you’re a superuser you
can by definition do bad things to the system. If a normal user could do
this, then this definitely would need fixing.


I agree but isn’t this a tiny bit fragile.
I don’t thing you can delete the FAT under dos with a copy command > :wink:
It’s also a concern (to me at least) since most system I’v seen
have all their program running as root. Who goes to the trouble
of creating dummy user for a deeply embedded system.

But then again rm -rf /* is pretty devasting as well > :wink:

Actually the nasty one is something like:

rm -rf * .o

:slight_smile:

QNX Training Services
dagibbs@qnx.com

Mario Charest wrote:

“Rick Lake” <> rwlake@SPAM.REDIRECTED.TO.DEV.NULL> > wrote in message
news:> 3A7723A1.47166998@SPAM.REDIRECTED.TO.DEV.NULL> …
I tend to disagree that this is a “problem”. If you’re a superuser you
can by definition do bad things to the system. If a normal user could do
this, then this definitely would need fixing.


I agree but isn’t this a tiny bit fragile.

it is fragile indeed. but as you pointed out below, there are more
things that could go wrong.

I don’t thing you can delete the FAT under dos with a copy command > :wink:

however, dos doesn’t know the concept of “superuser”

It’s also a concern (to me at least) since most system I’v seen
have all their program running as root. Who goes to the trouble
of creating dummy user for a deeply embedded system.

that I agree with you. that’s why “high risk program” developers (i.e.
driver writers) have to be very careful and test very thoroughly. but if
you mean that people run “normal apps” as root, while it’s not
necessary, then that’s a bad thing. (I often find installations that run
apps as root, because the operator was too lazy to figure out and solve
all of the permission issues; taking the easy way out. ugh…)

But then again rm -rf /* is pretty devasting as well > :wink:

I had “dinit -h /dev/hd0t77” in mind, but yours is pretty devastating
also :slight_smile: Every time I want to create a secondary filesystem on
/dev/hd0t78, I always check, check, double check before hitting enter.
(Really gives me the creeps :slight_smile: Contrary to QNX2, the dinit util doesn’t
give you a chance to confirm when diniting a HD partition; it just does
it immediately and beeps you that it was not a floppy, but then you’re
already too late :slight_smile:

rick

Mario Charest wrote:

A friend of mine pointed out how easy it was to overwrite the
.inodes and .bitmap files

cp file /.inodes and kaboum.

Shouldn’t this be “fix”

  • Mario

Mario Charest <mcharest@void_zinformatic.com> wrote:



I tried this under QNX4 and NTO and the filesystem won’t allow you to
unlink the inodes file.

#cp testfile /filefs/.inodes
cp: readtest → /filefs/.inodes
cp: Open dest for write failed. Unlink first? (y/N) y
cp: Can’t unlink file /filefs/.inodes
: Resource busy

A friend of mine pointed out how easy it was to overwrite the
.inodes and .bitmap files

cp file /.inodes and kaboum.

Shouldn’t this be “fix”

  • Mario

<jclarke@qnx.com> wrote in message news:9598th$agp$1@nntp.qnx.com

Mario Charest <mcharest@void_zinformatic.com> wrote:



I tried this under QNX4 and NTO and the filesystem won’t allow you to
unlink the inodes file.

#cp testfile /filefs/.inodes
cp: readtest → /filefs/.inodes
cp: Open dest for write failed. Unlink first? (y/N) y
cp: Can’t unlink file /filefs/.inodes
: Resource busy

Well apparently this is the case with newest release. The “problem”
occurs with older release. It was “fixed” :wink:

A friend of mine pointed out how easy it was to overwrite the
.inodes and .bitmap files

cp file /.inodes and kaboum.



Shouldn’t this be “fix”

  • Mario