[rsbac] To-Do List for 1.2.3

[Samuli Kärkkäinen]

On Sun, Sep 28, 2003 at 12:15:04AM +0200, Amon Ott wrote:
> > This is indeed one way to solve this issue. However if rsbac really were
> > path based it would also solve the "~/.Xauthority problem" and remove the
> > necessity of "restoring" all permissions after any rpm/deb update. It just
> > seems to me the path based approach would be cleaner, but it's also
> > possible the better solution is to have good user space utilities.
> 
> Path based control means dealing with strings instead of numbers, and it needs 
> a conflict scheme to deal with multiple names for a single file and renames. 
> The inode number has been chosen to have guaranteed unique file 
> identifications, and I do not want to change to paths.

Alright. For me the most important argument is that using inodes keeps the
kernel code simpler, and hence more stable. In the end of the day, I value
stability more than plentitude of features.

> The backup issue is did not occur as such a problem to me, because I have been 
> using it with success for years. However, we can add a few measures to speed 
> them up significantly. I already have an idea to use reference counters for 
> dirs, how many subdirs or files have attributes below them. If ref count is 
> 0, we can skip the whole sub tree.

This sounds really good. Being able to have a once a day light weight
cronjob that says "rsbac_backup_all / >/backups/`date -I`" is something
that'd make me happy. That would obviously make the --exclude options
unnecessary too, at least for my purposes.

> I agree that the current scheme to make a backup, update a package and restore 
> the backup is not the best of ways. We will have to improve on this, but it 
> requires some knowledge about the packages.

It just occured to me that the checkinstall utility
(http://asic-linux.com.mx/~izto/checkinstall/index.php) does things quite
close to what the rsbac software installation wrapper needs to do.
Checkinstall is a wrapper around any commands and detects what files are
modified by them, and uses that data to automatically build an
rpm/deb/tarball of the files. It works surprisingly well, downright
perfectly. Probably the same mechanism could be used for creating a wrapper
that preserves rsbac settings of any modified files. This would be better
than a package specific system because it'd also work for tarball based
installs and whatnot.

OTOH if the full backup/restore cycle can be made really fast, it might be
better to just use that always.

-- 
  Samuli Kärkkäinen                   |\      _,,,---,,_
 skarkkai at woods.iki.fi ---------ZZZzz /,`.-'`'    -.  ;-;;,_------
http://www.woods.iki.fi              |,4-  ) )-,_. ,\ (  `'-'
                                     '---''(_/--'  `-'\_)