[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: RFS: fsprotect (try #2)



Hello,

On Tuesday 21 April 2009, Maximiliano Curia wrote:
> Excerpts from Stefanos Harhalakis's message of mar abr 21 12:12:02 -0300 
2009:
> > fsprotect is 100% tied to a distribution. It cannot be an independent
>
> Anyway, it shouldn't be a native package, native packages need a new
> release to fix anything (packaging, typos, etc), also need a full upload
> for every change. It can be argued if there is any use for native packages
> anymore, and probably there isn't. So, please, don't upload a native
> package.

This is a 100% debian specific utility. Shouldn't it be a debian native 
package? Not making native means that I'd have to do two releases for each 
actual release (!) and maintain two trees for something that is debian 
specific. The source code is small and the most part of it is inside debian/. 
Have a look at the du:

$ du -sk fsprotect/*
264	fsprotect/debian
156	fsprotect/doc
56	fsprotect/initramfs-tools
20	fsprotect/lib
20	fsprotect/sbin

The fsprotect/initramfs-tools directory contains 100% debian specific scripts. 
If this is to become a non-native package, all debian-specific parts should go 
to debian/ dir which would be almost everything (!). Only the fsprotect/sbin 
and fsprotect/lib dirs aren't debian specific and they just contains two small 
helper scripts.

It just isn't reasonable (and even possible) to split the debian and non-
debian stuff.

> > /lib/fsprotect/fsprotect-protect
> >
> > and perhaps (in the future) hold other helper scripts too.
>
> Why is the script in /lib/fsprotect? Shouldn't it be better if its simply
> inside /sbin?

It's not a user-usable script. It's just a helper script. Just like 
/lib/udev/*, /lib/lsb/*, /lib/init/*, etc.

> Why fsprotect needs to break the FHS?

Based on /lib/init/rw and the directories that I mentioned above, I thought 
that this was the correct place to put it. If not, please suggest another 
location for it.

> > the /fsprotect directory will be used to mount filesystems inside it. 2
> > mounts per protected filesystem will exist in there.
> >
> > The /fsprotect/system and /fsprotect/tmp directories are required to
> > pre-exist at the time initramfs mounts the root filesystem.
>
> Then you might prefer to create those directories from a initramfs script.

I did that and it seems to work OK. However I thought of one catch: Currently 
fsprotect doesn't "protect" non-root filesystems when the root fs isn't 
protected. In the future this may change. In that case it will either need 
those directories to pre-exist or will need to create them on-the-fly but they 
will be created inside the real root fs. This means that they will be 
preserved in later boots and will need to be removed by -rm scripts.

For now I don't think there is any use in just protecting non-root 
filesystems, so I don't plan to add it unless there is a request for that.

In other words: This approach is OK for now.

> Is it posible to make fsprotect run only as a script of initramfs?

No. It has an init script that runs after non-root filesystems are mounted.

I've uploaded version 1.0.2 to mentors. It includes the /fsprotect directory 
removal and adds a documentation pdf which I planned to include in the next 
release. I also removed the duplicate ChangeLog file.


Reply to: