Les Mikesell írta:
Zoltan Boszormenyi wrote:
Les Mikesell írta:
Zoltan Boszormenyi wrote:
He was a bit tricky to
use chattr +i on /bin/login and some other progs.
BTW, although rpm complained that it cannot replace
those, why isn't it prepared for such scenarios?
RPM is made for Linux, it should certainly know
about special filesystem flags and handle them.
How should rpm handle it? Rpm has no way of knowing why the
How?
1. be able to specify special flags in the specfile and apply
them upon
install
2. detect if the filesystem doesn't handle such specials and make
note
of it in the rpmdb
3. clear them before uninstalling or upgrading
4. detect if it was modified, report it with rpmv
(skip this check if the rpmdb indicates it, see 2)
Why? What would the advantages be? Do they overcome the drawbacks of
rpm being able to change a file that you set the immutable flag on?
Mikkel
Yes, see 3.
What would be the point of having a special attribute if programs
can just ignore it?
What's the point of having a package manager if you can
overwrite everything by compiling from source or delete stuff?
What's the point of setting the immutable flag on a binary, doc or data
file that might - and eventually will - be replaced if you upgrade
its package?
What's the point of handling Unix/SELinux permissions by rpm
if you can simply chmod/chown everything?
I ran out of rhetoric questions. :-)
It's all a matter of programmer-vs.-programmer wars to show who is in
control.
My questions above weren't about war. Again, different POVs.
I tried to give some examples of ease of use vs manual control.
A1. you have package manager because you want easy installation
and you don't want to wait while the stuff compiles
A3. because it's easier to have everything have the proper permissions,
let rpm handle it.
and
A2. the packager may consider a file to be so essential that he wants it
immutable. but the upgrade of the package must also work without
manual override, i.e. without clearing immutable flag first.
You can compare it to the person who thought that the passwd program
should only talk directly to a tty and that programs should not be
able to use it. That lasted a few months - until another programmer
wanted his program to be able to change passwords and wrote 'expect'
to do it. A big waste of both people's time...
Agreed, that's unfortunate.
But your POV in the question above is wrong.
The point is to take advantage of something
where available.
Beg your pardon? The point of adding the immutable bit was so the
file couldn't be changed by ordinary means. It is, again, a waste of
both parties efforts as soon as someone adds the programming to bypass
its attempt at control.
But you already have it - you can use chattr from shell scripts or manually.
But chattr works only as root and you can only run rpm -[iU] as root
successfully anyway.
Hm. You can use chattr in pre and post scriptlets in rpm today. :-)
But rpmv won't tell you whether the fs-special flags were set
by rpm or by someone else.
I can certainly remember if I set this flag myself (e.g. have it documented)
or ask the collegues. If no one authorized has set it (like it was in
the case of
the intrusion) then I would expect that rpm were able to replace
a package with --force, even if some files have the immutable flag set.
(Or similar in case of other FSes than ext2/3/4.)
Actually, I have another rhetoric
question to back up my POV: what's the point of
supporting NX in the newer CPUs when you can
run the compiled kernel on older system where
the feature never activates?
For kernel features it isn't a rhetorical question. The answer is
always that Linus wants it to be that way.
