7:34 p.m.
I just had the idea to install FC2 Test 2 with the Reiser file system.
Boot off CD, run "linux reiserfs", format, install everything looks good, but
on
boot there's nothing but AVC errors about /sbin/init.
I am suspecting that the Reiser FS problems with SELinux aren't fixed, and this
is an impossible combination.
Am I wrong? Is there a way to install FC2 without issues on a Reiser file
system, if not the option to should be removed and some documentation should be
referenced.
Thanks for a great distro guys.
Nate Solberg
Information Systems Admin
High Country Media Group, LLC
Boone, NC
-------------------------------------------------
This webmail service provided by Appalachian Technologies
DSL, Dial-up, Networking and Expert Hosting
services for the High-Country and Western NC
http://www.apptechnc.net
9:03 a.m.
On Sun, 4 Apr 2004 nate(a)mountaintimes.com wrote:
I just had the idea to install FC2 Test 2 with the Reiser file system.
Boot off CD, run "linux reiserfs", format, install everything looks good, but
on
boot there's nothing but AVC errors about /sbin/init.
I am suspecting that the Reiser FS problems with SELinux aren't fixed, and this
is an impossible combination.
Am I wrong? Is there a way to install FC2 without issues on a Reiser file
system, if not the option to should be removed and some documentation should be
referenced.
Reiserfs does not support file labeling, although there is a patch in the
suse kernel for it (we would only want to apply something that is
upstreamable though).
- James
--
James Morris
<jmorris(a)redhat.com>
2:10 p.m.
James Morris wrote:
Reiserfs does not support file labeling, although there is a patch in
the
suse kernel for it (we would only want to apply something that is
upstreamable though).
I hope this patch will make it into FC2. I have a lot of machines that
are running on reiserfs, and can't easily be switched. This is for the
obvious reason that reorganising the filesystems is time consuming.
More importantly, though, there is an application which was developed
specifically with reiserfs in mind, and creates huge numbers of small
files. It would be difficult to run this under ext3.
Pete
2:22 p.m.
On Mon, 5 Apr 2004, Pete Chown wrote:
James Morris wrote:
> Reiserfs does not support file labeling, although there is a patch in the
> suse kernel for it (we would only want to apply something that is
> upstreamable though).
I hope this patch will make it into FC2.
It won't unless Hans accepts the patch upstream.
I have a lot of machines that are running on reiserfs, and can't
easily
be switched. This is for the obvious reason that reorganising the
filesystems is time consuming. More importantly, though, there is an
application which was developed specifically with reiserfs in mind, and
creates huge numbers of small files. It would be difficult to run this
under ext3.
You can probably solve this with a context mount, as you won't need
reiserfs for the entire box.
- James
--
James Morris
<jmorris(a)redhat.com>
3:07 p.m.
James Morris wrote:
> I hope this patch will make it into FC2.
It won't unless Hans accepts the patch upstream.
Would you accept a patch against the kernel spec file and SRPM contents?
In other words, if I make it easy for you, will it go in? Or is it
more problematic than this, for example that the patch won't apply
cleanly to the RedHat kernel?
You can probably solve this with a context mount, as you won't
need
reiserfs for the entire box.
I don't know that I'd be too keen on having part of the filesystem
unlabelled. Presumably anyone who gets root has full control over any
unlabelled files regardless of their SELinux credentials?
Most likely I'll be solving this problem with a customised kernel, if I
go for SELinux at all.
Pete
3:17 p.m.
On Mon, 5 Apr 2004, Pete Chown wrote:
James Morris wrote:
> > I hope this patch will make it into FC2.
> It won't unless Hans accepts the patch upstream.
Would you accept a patch against the kernel spec file and SRPM contents?
In other words, if I make it easy for you, will it go in? Or is it
more problematic than this, for example that the patch won't apply
cleanly to the RedHat kernel?
No. The patch must be acceptable upstream, in the mainline kernel.
> You can probably solve this with a context mount, as you won't need
> reiserfs for the entire box.
I don't know that I'd be too keen on having part of the filesystem
unlabelled. Presumably anyone who gets root has full control over any
unlabelled files regardless of their SELinux credentials?
It is labeled at the kernel level (like genfs mounts), SELinux controls
work normally, and root cannot do anything special that could not be done
with an xattr filesystem.
- James
--
James Morris
<jmorris(a)redhat.com>
8:38 a.m.
James Morris wrote:
The patch must be acceptable upstream, in the mainline kernel.
As I understand it, Hans Reiser has indicated that he will only accept
bugfixes for reiser3. It is therefore very unlikely that anyone could
come up with a patch which would be merged upstream. Reiser4 will
support file metadata from the beginning, but of course it's not
available yet.
I realised, though, that I don't really need to build a custom kernel.
All I need to make is one module ("sereiserfs") which I then load into
the normal kernel. I should be able to build that using the normal
RedHat kernel source plus the SuSE patch.
Assuming it works as expected, I'll announce it here for the benefit of
anyone else who wants to use reiserfs. I'm unlikely to build it until
FC2 is actually released though.
It is labeled at the kernel level (like genfs mounts), SELinux
controls
work normally, and root cannot do anything special that could not be done
with an xattr filesystem.
So is the idea that the whole filesystem gets the same label? That
sounds useful in some circumstances, but building a new reiserfs module
is more *fun*. :-)
Pete
8:45 a.m.
On Tue, 6 Apr 2004, Pete Chown wrote:
> It is labeled at the kernel level (like genfs mounts), SELinux
controls
> work normally, and root cannot do anything special that could not be done
> with an xattr filesystem.
So is the idea that the whole filesystem gets the same label?
Yes.
- James
--
James Morris
<jmorris(a)redhat.com>
8:38 a.m.
On Tue, Apr 06, 2004 at 09:45:24AM -0400, James Morris wrote:
On Tue, 6 Apr 2004, Pete Chown wrote:
> > It is labeled at the kernel level (like genfs mounts), SELinux controls
> > work normally, and root cannot do anything special that could not be done
> > with an xattr filesystem.
>
> So is the idea that the whole filesystem gets the same label?
Yes.
Out of curiosity how does this work with bind mounts, can you use context with a bind
mount?
Paul
9:49 a.m.
On Tue, 6 Apr 2004, Paul Nasrat wrote:
> > > work normally, and root cannot do anything special
that could not be done
> > > with an xattr filesystem.
> >
> > So is the idea that the whole filesystem gets the same label?
>
> Yes.
Out of curiosity how does this work with bind mounts, can you use context with a bind
mount?
Bind mounts ignore context options.
- James
--
James Morris
<jmorris(a)redhat.com>
8:17 a.m.
On Tue, 6 Apr 2004 23:38, Pete Chown <1(a)234.cx> wrote:
As I understand it, Hans Reiser has indicated that he will only
accept
bugfixes for reiser3. It is therefore very unlikely that anyone could
come up with a patch which would be merged upstream. Reiser4 will
support file metadata from the beginning, but of course it's not
available yet.
Hans and I get along well. I have used ReiserFS since the early days,
benchmarked it and tested it in various other ways, make detailed bug
reports, and generally helped it get accepted.
Hans told me that there would never be official support for XATTR on ReiserFS
3, which led to me removing ReiserFS from all my systems.
I think that it's quite safe to consider support for XATTR on Reiser3 to be
impossible for Red Hat.
That said, the "-o context=" mount option should do well for any situation
where you REALLY need ReiserFS. ReiserFS performs really well for Maildir
format mail spools on large mail servers, the original INN news spool, squid,
and for other applications that manage large numbers of small files. In all
those situations -o context will do really well.
In fact for such situations where you have a file system dedicated to one type
of file even when using other file systems using the -o context mount option
may be advisable. For Ext2/3 the space overhead of an xattr on each file is
not significant (based on my recollection of a conversation with sct it's one
xattr block per 1024 files). However labelling a file system with >1M files
will take quite a bit of time as will re-labelling such a file system after a
serious disk error. For large file systems of Ext2/3 using -o context will
save some significant amount of labelling time which is a definite benefit.
Currently mkfs.xfs in Fedora defaults to a 256 byte Inode (see below bugzilla
URL for the details). This means that existing XFS file systems will not be
good candidates for being labelled with SE Linux contexts. I believe that we
have never provided a method for install to an XFS root fs, so most use of
XFS in Fedora should be for /mail, /var/spool/news, /var/cache/squid, etc.
Using -o context for such file systems should provide significant benefits
for disk space use and performance.
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=120622
--
http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/ Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/ My home page
9:14 a.m.
Once upon a time Monday 12 April 2004 11:17 pm, Russell Coker wrote:
On Tue, 6 Apr 2004 23:38, Pete Chown <1(a)234.cx> wrote:
<snip>
Currently mkfs.xfs in Fedora defaults to a 256 byte Inode (see below
bugzilla URL for the details). This means that existing XFS file systems
will not be good candidates for being labelled with SE Linux contexts. I
believe that we have never provided a method for install to an XFS root fs,
so most use of XFS in Fedora should be for /mail, /var/spool/news,
/var/cache/squid, etc. Using -o context for such file systems should
provide significant benefits for disk space use and performance.
https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=120622
at the install boot screen append xfs as an option i.e linux xfs and you will
be able to install xfs from the get go. I currently have two test 2 systems
running xfs as the root file system one system has a 80 gig drive and the
other is 60 gig. im willing to help test things
Dennis
9:57 a.m.
On Tue, 13 Apr 2004 00:14, Dennis Gilmore <dennis(a)ausil.us> wrote:
> Currently mkfs.xfs in Fedora defaults to a 256 byte Inode (see
below
> bugzilla URL for the details). This means that existing XFS file systems
> will not be good candidates for being labelled with SE Linux contexts. I
> believe that we have never provided a method for install to an XFS root
> fs, so most use of XFS in Fedora should be for /mail, /var/spool/news,
> /var/cache/squid, etc. Using -o context for such file systems should
> provide significant benefits for disk space use and performance.
>
> https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=120622
at the install boot screen append xfs as an option i.e linux xfs and you
will be able to install xfs from the get go.
Even on the root fs? I wasn't aware of this.
Is it possible to pass "-i size=512" to mkfs.xfs through the GUI or do you
have to run mkfs.xfs from the command line to do so?
I currently have two test 2
systems running xfs as the root file system one system has a 80 gig drive
and the other is 60 gig. im willing to help test things
Well if you have 256 byte Inodes then your test results may make you unhappy.
Lots of disk space used and no good way of reclaiming it. But I would be
interested to hear about your test results apart from issues of performance
and wasted disk space...
--
http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/ Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/ My home page
10:10 a.m.
Once upon a time Tuesday 13 April 2004 12:57 am, Russell Coker wrote:
On Tue, 13 Apr 2004 00:14, Dennis Gilmore <dennis(a)ausil.us>
wrote:
> > Currently mkfs.xfs in Fedora defaults to a 256 byte Inode (see below
> > bugzilla URL for the details). This means that existing XFS file
> > systems will not be good candidates for being labelled with SE Linux
> > contexts. I believe that we have never provided a method for install
> > to an XFS root fs, so most use of XFS in Fedora should be for /mail,
> > /var/spool/news, /var/cache/squid, etc. Using -o context for such file
> > systems should provide significant benefits for disk space use and
> > performance.
> >
> > https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=120622
>
> at the install boot screen append xfs as an option i.e linux xfs and you
> will be able to install xfs from the get go.
Even on the root fs? I wasn't aware of this.
yes both systems only have xfs as the filesystem
Is it possible to pass "-i size=512" to mkfs.xfs through
the GUI or do you
have to run mkfs.xfs from the command line to do so?
i will do some testing to see if it can be either passed as a boot option or
specifed in the gui think it would probably only be available as a boot time
option same as enabling xfs support.
> I currently have two test 2
> systems running xfs as the root file system one system has a 80 gig
> drive and the other is 60 gig. im willing to help test things
Well if you have 256 byte Inodes then your test results may make you
unhappy. Lots of disk space used and no good way of reclaiming it. But I
would be interested to hear about your test results apart from issues of
performance and wasted disk space...
Ill let you know how it goes ill re-enable selinux
Dennis
10:22 a.m.
On Tue, 13 Apr 2004 01:10, Dennis Gilmore <dennis(a)ausil.us> wrote:
> Is it possible to pass "-i size=512" to mkfs.xfs
through the GUI or do
> you have to run mkfs.xfs from the command line to do so?
i will do some testing to see if it can be either passed as a boot option
or specifed in the gui think it would probably only be available as a boot
time option same as enabling xfs support.
I would be shocked if there was a boot option to pass such options to
mkfs.xfs. XFS has lots of tunable options, using them all in boot options
would not make sense to me, even if it wasn't for the fact that different
file systems may want different mkfs options.
There are XFS options -d for data section, -l for log, and -b for block size.
Having boot options for all of these would be confusing at best.
--
http://www.coker.com.au/selinux/ My NSA Security Enhanced Linux packages
http://www.coker.com.au/bonnie++/ Bonnie++ hard drive benchmark
http://www.coker.com.au/postal/ Postal SMTP/POP benchmark
http://www.coker.com.au/~russell/ My home page
3:20 p.m.
On Mon, 2004-04-05 at 07:03, James Morris wrote:
Reiserfs does not support file labeling, although there is a patch in
the
suse kernel for it (we would only want to apply something that is
upstreamable though).
Are any other file systems besides ext2/3 usable for SELinux?
thx - Karsten
--
Karsten Wade, Sr. Tech Writer
this is not the .signature you are looking for
http://people.redhat.com/kwade/
gpg fingerprint: 2680 DBFD D968 3141 0115 5F1B D992 0E06 AD0E 0C41
3:26 p.m.
Karsten Wade (kwade(a)redhat.com) said:
On Mon, 2004-04-05 at 07:03, James Morris wrote:
> Reiserfs does not support file labeling, although there is a patch in the
> suse kernel for it (we would only want to apply something that is
> upstreamable though).
Are any other file systems besides ext2/3 usable for SELinux?
XFS supports labels, as I recall.
Bill
4:21 p.m.
On Mon, 5 Apr 2004, Bill Nottingham wrote:
Karsten Wade (kwade(a)redhat.com) said:
> On Mon, 2004-04-05 at 07:03, James Morris wrote:
> > Reiserfs does not support file labeling, although there is a patch in the
> > suse kernel for it (we would only want to apply something that is
> > upstreamable though).
>
> Are any other file systems besides ext2/3 usable for SELinux?
XFS supports labels, as I recall.
devpts can also be labeled with xattrs.
- James
--
James Morris
<jmorris(a)redhat.com>
7319
days inactive
7326
days old
selinux@lists.fedoraproject.org
18 comments
9 participants
participants (9)
-
Bill Nottingham -
Dennis Gilmore -
James Morris -
Karsten Wade -
nate＠mountaintimes.com -
Paul Nasrat -
Pete Chown -
Russell Coker -
Stephen C. Tweedie