[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20070402104205.GB17656@mother.brazil.openwall.com>
Date: Mon, 2 Apr 2007 14:42:05 +0400
From: Grigoriy Strokin <grg@...nwall.com>
To: owl-users@...ts.openwall.com
Subject: Re: Owl-based desktop environment
Solar,
Thanks for your comments!
On Mon, Apr 02, 2007 at 04:56:53AM +0400, Solar Designer wrote:
> Yes - Dmitry has already explained that you should be able to use most
> RPMs from RHEL4 and FC3, as well as some from FC4.
And what exactly is Owl-incompatible in FC4? Specifically,
can I use xorg-x11-* from FC4 to get a relatively fresh X.org?
> However, Red Hat's packages of X and related stuff have too many
> dependencies that you might not want to bring in (Qt, Kerberos). If so,
> you might pick their SRPMs and rebuild from source with minor tweaks to
> avoid the dependencies. If you do that, then SRPMs from a later version
> of Fedora will likely work.
OK, then I think I will use binary packages when they work, and the
source packages when I want to eliminate undesired dependencies.
> > 2) What is the best way to install X.org? Again, I thought
> > about downloading all Fedora RPMs with names starting from
> > xorg-x11-*, but they do not form a complete set:
> > there is xterm-*, which doesn't start with xorg-x11-*.
>
> Yes, you'd have to download more and more of their packages until you
> have all of the dependencies satisfied.
I think I will just download all FC's RPMs first. This is only 3 GB, and
I've got a laptop with a 120 GB hard disk to eliminate a possibility of
running out of disk space soon :-)
> I can provide you with working
> minimal lists of X-related packages from Fedora as of two years ago,
> assuming that you go for the rebuilds (otherwise the lists would be much
> longer... but you might actually save time by just installing stuff
> rather than rebuilding, so it's up to you).
I guess that rebuilding everything will be painful because of the number
of packages: I cannot just type 'make' and wait for all those 100
packages to compile because I suspect that quite a few packages will
require a customized configure/make invocation. So I will use a mix of
binary/source rpms :-)
>
> I don't think there's one "right way". I'm not aware of a perfect one.
> [...]
Thanks for your suggestions. I will try using another virtual console
for logging in as root until I get too bored with this approach :-)
> If you need to do things as root very often, then I'm afraid that you'll
> have to use "su -" despite of its risks.
One of operations I'll need often is halt/reboot. How do I use
shutdown as grg without making /sbin/shutdown suid root? Man shutdown
says about /etc/shutdown.allow, but I think it assumes suid root anyway.
> > ssh r_grg@...alhost ?
>
> As others have pointed out, this is the same as "su - r_grg" from a
> security standpoint.
> > What about using passwords?
>
> I don't understand this question - it is too generic, while you probably
> wanted to ask something more specific.
I meant that disabling the root password altogether might add more
security. For example, if I decide to use either su or ssh
root@0 despite their unsecurity, I think about the following scheme:
1) Disable the password for root and add a ssh key to
~root/.ssh/authorized_keys.
2) Do not store this ssh key in ~grg/.ssh/, but create another
account grg2 and place the ssh key there. Therefore, grg can never
become root even if the account is compromised.
3) Allow grg2 to login only from the physical console.
4) Every time I need to become root, switch to another
console where grg2 is logged in, and run ssh root@0 there (and type
the passphrase).
Does it make sense?
--
Grigoriy.
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
