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

Re: [Bacula-devel] Implementation of acls and extended attributes


On Saturday 25 October 2008 21:47:10 Marco van Wieringen wrote:
> 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.

Yes, these are very nice changes that add a lot of functionality to Bacula.  
Many thanks.

> 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@xxxxxxx>
>    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

Nice, because this is an aimportant project.

> 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))

Yes, I think we should keep backward compatibility, and the way you suggest is 
one way, but after thinking about this, I am beginning to wonder if we don't 
already have a problem of portability.   Basically a Bacula tape should be 
able to be read on any system.  If the system does not have the type of ACLs 
that were stored then it cannot restore them and should report at least one 
error or warning messs.

I am now wondering if the author of the ACL code did not put different types 
of ACLs for different systems into a single ACL stream.  That basically makes 
it non-portable.

In my opinion, the proper solution to this is to define different streams for 
each specific ACL type.  That eliminates the need for having @p, ... and such 
to distinguish ACL types.  The other solution would be to reserve the first 
word of each ACL record to indicate the sub-stream (i.e. acl type) type, but 
since we have have a very large number of stream possibilities, I think we 
should use new stream ids.  

In fact, I suggest, we reserver streams 1000-1999 for ACL streams, and we 
implement new separate stream identifiers for each existing and all the new 
streams.  Thus the code should be fully upward compatible, and Bacula will 
still be able to read old Volumes.

> 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. */

Yes, originally certain Extended attribute data for Win32 was put into this 
stream.  Subsequently we added BackupRead/Write streams.

> 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.a
> 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.

How is this handled currently?

It sounds like you need a name, value pair.  In general the simplest way to do 
this is if the name and value are character strings, one separates them by a 
zero byte.  Then a single Bacula ACL stream record will have the name and the 
value.  If the name or the value can take on binary values, then generally, 
we define a record that is:

 name-length  (32 bits in network byte order)
 value-length (32 bits in network byte order)

All these items would use Bacula's serialization routines, which ensures that 
they can be read and written by any architecture.  See serial.h and serial.c 
in src/lib for details.

Best regards,


> 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
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's
> challenge Build the coolest Linux based applications with Moblin SDK & win
> great prizes Grand prize is a trip for two to an Open Source event anywhere
> in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Bacula-devel mailing list
> Bacula-devel@xxxxxxxxxxxxxxxxxxxxx
> https://lists.sourceforge.net/lists/listinfo/bacula-devel

This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
Bacula-devel mailing list

This mailing list archive is a service of Copilotco.