[Bacula-devel] Implementation of acls and extended attributes

[Marco v. W. <mv...@pl...>]

Hi,

Before I continue making changes to bacula I was wondering what the
global consensus is on certain aspects which are on the projects list of
bacula.

Most people might not know me and I must say that I started using Bacula
about 2 months ago. From then on I pushed some changes back to Kern
which got integrated just recently. Most important ones are

- libtool support for supporting shared libs with the bacula common
  functions (like the libbac, libbacfind and libbacsql)
- support for copy jobs that help for disk-to-disk-to-tape backups
  (implemented in bacula as the pooluncopiedjobs copy job
   which implements a SQL query first send to the bacula list by
   Ulrich Leodolter)
- Legato compatibility with support for add and delete keyword when
  selecting the files to restore.
- Support for the new libsec interface in Solaris 10 and higher which
  make it possible to backup and restore ZFS/NFSv4 type of acls on
  Solaris (which is important as Solaris is moving to ZFS for most
  systems either sooner or later). This patch makes sure you don't get
  zillions of errors in your log when enabling acl support on a zfs
  filesystem.

My main interest in Bacula comes from a personal need to have a solid
backup on my mostly Solaris based environment. So I mainly focus on
Solaris specific items. That's also one of the reasons my main
contributions until now have been on either generic or Solaris specific
patches.

But when looking at something that might give me something TODO the next
weeks I have been looking through the projects list in the current devel
version. I'm looking into things that I find myself interesting and are
not to big to implement in a couple of weeks. Some thing that I find
interesting and is not directly Solaris based is implementing extended
attributes backup. (To be honest I think its mostly Linux and xBSD)

The current entry in the projects file lists this:

Item: Store and restore extended attributes, especially
      selinux file contexts
   Date: 28 December 2007
   Origin: Frank Sweetser <fs...@wp...>
   What: The ability to store and restore extended attributes on
         filesystems that support them, such as ext3.

   Why: Security Enhanced Linux (SELinux) enabled systems make extensive
        use of extended attributes.  In addition to the standard user,
        group, and permission, each file has an associated SELinux
        context stored as an extended attribute.  This context is
        used to define which operations a given program is permitted to
        perform on that file. Storing contexts on an SELinux system is
        as critical as storing ownership and permissions. In the case
        of a full system restore, the system will not even be able to
        boot until all critical system files have been properly
        relabeled.

 Notes: Fedora ships with a version of tar that has been patched to
        handle extended attributes. The patch has not been
        integrated upstream yet, so could serve as a good
        starting point.

        http://linux.die.net/man/2/getxattr
        http://linux.die.net/man/2/setxattr
        http://linux.die.net/man/2/listxattr
        ===
        http://linux.die.net/man/3/getfilecon
        http://linux.die.net/man/3/setfilecon

I have done some preliminary investigations into what might be needed
and its seems its not to difficult. I looked at 2 specific
implementations of extended attributes (in star and rsync) and the whole
code is not to difficult. I think we should drop the whole specific
selinux stuff and concentrate on extented attributes. What I found out
is that the listxattr, getxattr and setxattr functions already handle
selinux too (at least on centos 5.2 where I tested a small c program)
So we can forget about the getfilecon and setfilecon call as this data
is also returned from the xattr calls.

When thinking about this more I first had the idea to store the extended
attributes in the acl stream currently already there. When adding
support for Solaris ZFS acls I already had a look at that particular
part of the code. I think however that the current code could use some
markup chars so we know what type of acl is in the stream so we can
give better errors when one tries to restore a stream from one server
on an other server. Myself I was thinking about preprending the acl
string with a identifier which indicates what type of acl it is.

I was thinking something like this (also keeping in mind backwards
compatibility)

@p - posix acl
@z - zfs/nfsv4 acl
@s - selinux security context
@x - extented attribute

When the acl doesn't start with a @ its an old style acl (from older fd
which will fallback to the old acl code (posix acls))

But when looking somewhat better I found out that for Windows we already
have a seperate attribute stream named STREAM_UNIX_ATTRIBUTES_EX which
stores the extended attributes of a Windows file. Only the comment in
baconfig.h states

/* Extended Unix attributes with Win32 Extended data.  Deprecated. */

But the code seems to be there, only for the Unix case its mostly empty.
So this makes me think, should I use the STREAM_UNIX_ATTRIBUTES_EX,
should I create a new stream for example STREAM_UNIX_EXTENDED_ATTRIBUTES
or should I keep my first idea and stuff it into the acl stream.

When not using the acl stream method I still think adding something
that identifies the type of acl will gives us somewhat better error
reporting on restoring acls.

Then the next thing is how are we gonna encode the attributes. I think
something with ASN1 is an idea (and I already see some other streams
using that too) An extended attribute is something like this:

- name
- name_len
- value
- value_len

This seems to make it a good fit for encoding it with ASN1 with a couple
of octetstring variables.

Ok thats it for now, I would welcome any input on a possible direction.
Up until now its been more or less investigation into how difficult
things might be but as it seems reasonable straightforward I think we
can start thinking about a possible implementation of things.

Marco