Re: ssh -X shop problem...
- From: Craig White <craig@xxxxxxxxxxxxx>
- Date: Tue, 28 Nov 2006 15:14:59 -0700
On Tue, 2006-11-28 at 16:24 -0500, Gene Heskett wrote:
On Tuesday 28 November 2006 10:42, Craig White wrote:
----I previously supplied the link to the information on SELinux to you the
first time you got in a tizzy and I will supply it again...
If you want to relabel the entire file system - that is a prerogative
that you enjoy but clearly not the only method available to you.
Knowledge is power...perhaps you want to absorb the information on the
above since 'local policy' is likely to be more enduring. Learning how
to use tools such as chcon might also prove useful.
Fine, go ahead and do a 'man chcon'. Now tell me what 'CONTEXT' means...
Without that definition the whole manpage may as well be written in
ummm...in section 1 in the above link there actually is a description of
'CONTEXT' - what they are and how to view them. I can lead you right to
it if you want but it's rather unfair to ask me to spoon feed you.
Fine, I can do that. But the chances of its working within the framework----
of amanda's view of security are slim to none when the limitations of the
rpm package system are applied. This has been discussed to death with no
viable solution being developed on either side of this divide. Up till
now, if one wanted an amanda install that Just Worked(TM), one followed
the build instructions for amanda, and it Just Worked(TM).
the only fundamental difference between an install from a tarball and an
install from an rpm is the predictability of where the files are
installed, the package requirements and upgrading. If you want
consistency, rpm is the way to do it. If you want to continue your
haphazard ways, don't bother with rpm packaging. The way the program
runs should be no different whether it was installed via rpm or
configure && make && make test && make install
----Also, I find it really hard to believe that someone who logs in asroot,
runs GUI as root actually changes to another user to ./configure &&make
&& make test before changing back to root to make install.
Because thats one of the things that makes amanda fairly secure, it runs
as an unpriviledged user, only doing suid root for those portions of its
job that require it. Strangely for you I suppose, I find it a perfectly
sensible method of obtaining some security. After all, amanda has been
around for about as many years as linux, probably longer. I came into
camp in 1998 when it was at about 2.4.2p1, now its 2.5.1p2, in late 2006.
The ChangeLog starts with version 2.3.0, but the first time a change was
dated was quite some time later, after version 2.4.0p1, and that was in
1998. So I think amanda knows just a wee tiny bit about security, and
probably more than this recent PHB hire, selinux.
I was talking about the build process and you are talking about run-time
security. It would be nice if you could stay on the same page.
SELinux has been around at least since FC-3...you've just been sleeping.
SELinux has been part of Fedora and RHEL for more than 2 years now.
The rpm packagers have demonstrated on numerous occasions that they do not----
fully understand the system of permissions amanda manipulates as she
wanders through the the dle's given, always running with just enough
perms to get the job done and no more.
what? - lots of people, including myself have run the rpm packaged
amanda without issue. I never saw a need to install from source. The
only issue that seemed to be resolved from source installation was the
ability to span tapes but if that was the point, then probably there are
better back up programs available which is why I went to bacula.
Sure, I'm willing to see if I can make an installable rpm, but seeing as----
how the use of rpm instead of locally built srcs forces so many
compromises into amanda that until rpm is fixed, a just works amanda
install, one that also works 100% for recovery, is probably just a
again, install from tarball or install from rpm packaged from the same
tarball is the same program that ends up getting installed. It's just
installed in a predictable fashion that can be repeated on more than one
The only reason that I suggested the rpm was to investigate the spec
file to see what is done to set security contexts (if anything) for
selinux peace with amanda.
If you are not going to read through the selinux information that I've
provided to you twice now and you still haven't gotten through the first
section which clearly describes what security contexts are, then just
disable selinux and be done with it.
fedora-list mailing list
To unsubscribe: https://www.redhat.com/mailman/listinfo/fedora-list