RSBAC working with SGI XFS 1.0


From: K Mitchell Russell <kmrussel@hsc.vcu.edu>
Subject: RSBAC working with SGI XFS 1.0
Date: Sat, 5 May 2001 20:31:04 -0400 (EDT)

Next Article (by Subject): Re: RSBAC working with SGI XFS 1.0 Keith Matthews
Previous Article (by Subject): Re: RSBAC vs. postfix Amon Ott
Next in Thread: Re: RSBAC working with SGI XFS 1.0 Keith Matthews
Articles sorted by: [Date] [Author] [Subject]


Colleagues,

SGI's XFS file system was released at version 1.0, May 1st.  Now that
both XFS and RSBAC have been officially released, I have been testing
them together and so far all seems well.  I patched a vanilla 2.4.3
kernel with the following (in order):

patch-int-2.4.3.1 (Int'l crypto patch - not relevent)
linux-2.4-xfs-1.0.patch (SGI XFS patch)
linux-2.4.3-core-xfs-1.0.patch (SGI XFS 2.4.3 patch)
patch-2.4.3-v1.1.1 (RSBAC 1.1.1 patch)

The patches all worked effortlessly except the RSBAC patch needed two
hunks added by hand (Makefile and arch/i386/kernel/entry.S) due to the
XFS patch.

System is a dual PII450 with 256MB RAM, 18GB SCSI harddisk (AIC7xxx)
running RedHat 7.1.  All partitions are XFS including root partition.

System runs fine with AUTH enabled (haven't added RC, MAC, or ACL yet)

There are two issues I would like to raise:

1) I recall Stanislav Ievlev submitted on April 3rd a problem with
rsbac_check() on reiserfs.  I decided to enable CONFIG_RSBAC_INIT_CHECK
to test this on XFS.  On first boot, it detects bad inodes:

May  5 19:15:39 loxias kernel: rsbac_do_init(): Forcing consistency
check.
May  5 19:15:39 loxias kernel: rsbac_check(): fd_item for bad inode
1897350 on device 08:03, list 0, removing!
May  5 19:15:39 loxias kernel: rsbac_check(): fd_item for bad inode
1901320 on device 08:03, list 10, removing!
May  5 19:15:39 loxias kernel: rsbac_check(): fd_item for bad inode
1901321 on device 08:03, list 11, removing!
May  5 19:15:39 loxias kernel: rsbac_check(): Device 08:03 has 1
fd-items (19 removed (0 on wrong list, 3 bad inodes, 0 dtimed inodes, 16
had only default values), 0 unlinked inodes) and 16 dirty lists
May  5 19:15:39 loxias kernel: rsbac_check(): Sum of 1 Devices with 1
fd-items
May  5 19:15:39 loxias kernel: rsbac_check(): 0 dev-items
May  5 19:15:39 loxias kernel: rsbac_check(): 0 ipc-items
May  5 19:15:39 loxias kernel: rsbac_check(): 4 user-items
May  5 19:15:39 loxias kernel: rsbac_check(): 9 process-items
May  5 19:15:39 loxias kernel: rsbac_check(): Total of 14 registered
rsbac-items, 16 lists dirty
May  5 19:15:39 loxias kernel: rsbac_check_auth(): 0 process-items
May  5 19:15:39 loxias kernel: rsbac_check_auth(): Device 08:03 has 2
fd-items (0 removed (0 bad inodes, 0 dtimed inodes, 0 had no members), 0
unlinked inodes) and 0 dirty lists
May  5 19:15:39 loxias kernel: rsbac_check_auth(): Sum of 1 Devices with
2 fd-items
May  5 19:15:39 loxias kernel: rsbac_check_auth(): Total of 2 registered
auth items, 0 lists dirty
May  5 19:15:39 loxias kernel: rsbac_do_init(): Ready.
May  5 19:15:39 loxias kernel: rsbacd(): Initializing.
May  5 19:15:39 loxias kernel: rsbac_init(): Started rsbacd thread with
pid 11
May  5 19:15:39 loxias kernel: rsbac_init(): Ready.

But then system comes up fine.  On second boot, everything seems OK:

May  5 19:29:12 loxias kernel: rsbac_do_init(): Forcing consistency
check.
May  5 19:29:12 loxias kernel: rsbac_check(): Device 08:03 has 1
fd-items (0 removed (0 on wrong list, 0 bad inodes, 0 dtimed inodes, 0
had only default values), 0 unlinked inodes) and 0 dirty lists
May  5 19:29:12 loxias kernel: rsbac_check(): Sum of 1 Devices with 1
fd-items
May  5 19:29:12 loxias kernel: rsbac_check(): 0 dev-items
May  5 19:29:12 loxias kernel: rsbac_check(): 0 ipc-items
May  5 19:29:12 loxias kernel: rsbac_check(): 4 user-items
May  5 19:29:12 loxias kernel: rsbac_check(): 9 process-items
May  5 19:29:12 loxias kernel: rsbac_check(): Total of 14 registered
rsbac-items, 0 lists dirty
May  5 19:29:12 loxias kernel: rsbac_check_auth(): 0 process-items
May  5 19:29:12 loxias kernel: rsbac_check_auth(): Device 08:03 has 2
fd-items (0 removed (0 bad inodes, 0 dtimed inodes, 0 had no members), 0
unlinked inodes) and 0 dirty lists
May  5 19:29:12 loxias kernel: rsbac_check_auth(): Sum of 1 Devices with
2 fd-items
May  5 19:29:12 loxias kernel: rsbac_check_auth(): Total of 2 registered
auth items, 0 lists dirty
May  5 19:29:12 loxias kernel: rsbac_do_init(): Ready.
May  5 19:29:12 loxias kernel: rsbacd(): Initializing.
May  5 19:29:12 loxias kernel: rsbac_init(): Started rsbacd thread with
pid 11
May  5 19:29:12 loxias kernel: rsbac_init(): Ready.

Looks to me like rsbac_check() checks out OK here, and system seems to
run fine.  Any comments?  Would it be reasonably safe to continue with
the CONFIG_RSBAC_INIT_CHECK with these results?

2) XFS provides ACLs as well as RSBAC providing ACL module.  I have not
delved into this yet, but I assume these are completely different ACLs
(i.e. I cannot access ACLs set in XFS through RSBAC ACL module).  Even
if the two are not compatible, I hope they may co-exist in benevolence.
I will continue to explore this, however if anyone with more knowledge
about it would care to comment, I would very much appreciate it.

Anyone else working with XFS and RSBAC?  If so please comment, as I
would like to see XFS added to the 'Compatability' list of RSBAC soon.

Best Regards,
Mitchell
   
________________________________________________________________________
K. Mitchell Russell, M.D.                        |  kmrussel@hsc.vcu.edu
Research Fellow, MedITAC Research Lab            |    www.meditac.com


-
To unsubscribe from the rsbac list, send a mail to
majordomo@rsbac.org with
unsubscribe rsbac
as single line in the body.

Next Article (by Subject): Re: RSBAC working with SGI XFS 1.0 Keith Matthews
Previous Article (by Subject): Re: RSBAC vs. postfix Amon Ott
Next in Thread: Re: RSBAC working with SGI XFS 1.0 Keith Matthews
Articles sorted by: [Date] [Author] [Subject]


Go to Compuniverse LWGate Home Page.