On Sunday 07 September 2008 22:53:47 Frank Sweetser wrote:
> Kern Sibbald wrote:
> > Hello Frank,
> >
> > I would like to understand what the difference between:
> >
> > 1. Normal ACLs that are referenced through libacl.
>
> Normal ACLs are a distinct property of a file (like the owner or mode) that
> just allow more flexible control over which users have access to a file
> than the traditional user/group/other unix model.

By the way for those who are not aware, these kinds of attributes or access 
control lists are already backed up by Bacula providing the appropriate 
libraries exist on the OS.

>
> > 2. Extended attribute referenced by the API you show below.
>
> Extended attributes are another distinct property, consisting of simple
> key/value pairs.  They're similar to NTFS alternative data streams, or
> Apple resource forks.  Get getfattr and setfattr commands can be used to
> examine the extended attributes of a file.  For example, if I run getfattr
> on my home directory an an SELinux enabled machine I get this:
>
> [fs@spook ~]$ getfattr -d -m . .
> # file: .
> security.selinux="system_u:object_r:user_home_dir_t:s0\000"
>
> Here's a little more general information on extended attributes on linux.
>
> http://linux.about.com/library/cmd/blcmdl5_attr.htm
>
> For the most part, the kernel itself doesn't pay any particular attention
> to extended attributes.  The one major exception (that I know of, anyway)
> is SELinux.

OK, so the main point here that interested me is that these attributes need to 
be backed up in addition to or at the same time as the normal acls are backed 
up.

>
> > 3. Selinux security contexts which are referenced through the
> >   getfilecon and setfilecon API.
>
> First, the 30 second SELinux tutorial.
>
> On an SELinux system, all objects (including files, processes, ports, etc)
> have a context.  Looking at the getfattr example above, you can see that my
> home directory has a context of system_u:object_r:user_home_dir_t:s0 (the
> meaning of the colon separated values isn't important as far as Bacula
> cares). Files have their contexts stored on disk as extended attributes
> with a label of 'security.selinux', and processes have a context which is
> derived from the context of the executable file.
>
> A policy which gets loaded into the kernel then defines what operations a
> given context is allowed to perform on other contexts.  For example, the
> apache process might be restricted such that it is not allowed to execute
> any programs that aren't labeled with a CGI context.
>
> If a file is missing the extended attribute that defines its label, it's
> roughly equivalent to having permissions of 000.

Thanks.  I ran Selinux for perhaps 6 months in FC4, but found it was a big 
pain and extremely complicated.  When I upgraded to FC5 I had to turn it off 
because the system would not run with it in enforce mode, and in permissive 
mode it was generating thousands of events -- a few I could have fixed but 
thousands was out of the question.  It has been off since.

>
> > In particular, does Bacula need to backup normal ACLs, Extended ACLs and
> > Selinux security contexts if all three APIs are available on a system
> > (such as my CentOS 5.2 system)??  Or does backing up/restoring extended
> > ACLs automatically include the others????
>
> ACLs and extended attributes are completely separate from each other, so
> backing up one won't do anything with the other.

Yes, thanks. That was what I thought but now you have confirmed it.

>
> As for extended attributes and SELinux context, since the context is
> implemented as an attribute I *believe* that backing up all extended
> attributes will properly grab all contexts.  Running strace on commands
> that examine file contexts suggests that getfilecon/setfilecon functions
> are just wrappers around getxattr/setxattr that go straight to the correct
> attribute.
>
> Does that all make more sense now?

Yes, thanks.  

I was hoping this would be easy, but it is looking more complex than I 
imagined due to the need to handle both acls and xattrs.  The ifdefing of the 
current acl implementation is complicated because it attempts to handle every 
favor of Unix. Saving/restoring both acls and extended attributes might 
require a new Volume stream which requires more work than I had planned for 
this project.    At least I know what it involves from the acl/xattr side, 
and the API for getting and setting the xattrs is straight forward 
(essentially the same as how Bacula handles acls, but with different 
subroutine names).  Now I need to look at the Bacula code more in detail to 
see if it is possible to implement it for version 3.0.0 ...

Best regards,

Kern



-------------------------------------------------------------------------
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-users mailing list
Bacula-users AT lists.sourceforge DOT net
https://lists.sourceforge.net/lists/listinfo/bacula-users