xhost +localhost
Gert Cuykens
complaining about acces controle. I did xhost +localhost but it still
wont start :(
_______________________________________________
freebsd-...@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-questions
To unsubscribe, send any mail to "freebsd-questi...@freebsd.org"
Louis LeBlanc
--NDin8bjvE/0mNLFQ
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
On 02/02/05 06:58 PM, Gert Cuykens sat at the `puter and typed:
> i want a screensaver but the ....... xscreensaver daemon wont start
> complaining about acces controle. I did xhost +localhost but it still
> wont start :(
If you're trying this on 5.3, the syntax has changed. Try something
like this:
xhost local:
Exactly as typed above.
Lou
--
Louis LeBlanc FreeBSD-at-keyslapper-DOT-net
Fully Funded Hobbyist, KeySlapper Extrordinaire :)
This is a list only address, and the return address is a black hole!
Send off-list email to: leblanc at keyslapper d.t net
Key fingerprint = C5E7 4762 F071 CE3B ED51 4FB8 AF85 A2FE 80C8 D9A2
Modesty:
The gentle art of enhancing your charm by pretending not to be
aware of it.
-- Oliver Herford
--NDin8bjvE/0mNLFQ
Content-Type: application/pgp-signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (FreeBSD)
iD8DBQFCAUCWr4Wi/oDI2aIRAvMfAKCCO1JHs9AySDkvZOfwkr7IwLefiACgkIks
10QU9ZE0KSOgDqWLO+b055E=
=ByqN
-----END PGP SIGNATURE-----
--NDin8bjvE/0mNLFQ--
Chuck Swiger
> On 02/02/05 06:58 PM, Gert Cuykens sat at the `puter and typed:
>> i want a screensaver but the ....... xscreensaver daemon wont start
>> complaining about acces controle. I did xhost +localhost but it still
>> wont start :(
>
> If you're trying this on 5.3, the syntax has changed. Try something
> like this:
>
> xhost local:
>
> Exactly as typed above.
Please tell me you are joking.
I remember learning to use "xhost +" in 1989 or '90 on X11--, before the
command improved to take hostnames as arguments to control which connections
were allowed and which should be refused on a per-host basis. At the time,
there were so few machines running X that malicious X connections were not a
significant concern.
Having "xhost +localhost" work the same way as "xhost +foo.cmu.edu"-- to avoid
treating the local host as a special case-- was a good idea fifteen years ago.
I do not have a perfect record of suggesting things in a way that does not
break backwards compatibility, but one should attempt to make the distinction
between "changing something which was broken in order to get to something
reasonable" and "changing something reasonable into something broken".
--
-Chuck
Louis LeBlanc
--Fig2xvG2VGoz8o/s
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
On 02/02/05 05:02 PM, Chuck Swiger sat at the `puter and typed:
> Louis LeBlanc wrote:
> > On 02/02/05 06:58 PM, Gert Cuykens sat at the `puter and typed:
> >> i want a screensaver but the ....... xscreensaver daemon wont start
> >> complaining about acces controle. I did xhost +localhost but it still
> >> wont start :(
> >
> > If you're trying this on 5.3, the syntax has changed. Try something
> > like this:
> >
> > xhost local:
> >
> > Exactly as typed above.
>
> Please tell me you are joking.
>
> I remember learning to use "xhost +" in 1989 or '90 on X11--, before the
> command improved to take hostnames as arguments to control which connections
> were allowed and which should be refused on a per-host basis. At the time,
> there were so few machines running X that malicious X connections were not a
> significant concern.
>
> Having "xhost +localhost" work the same way as "xhost +foo.cmu.edu"-- to avoid
> treating the local host as a special case-- was a good idea fifteen years ago.
>
> I do not have a perfect record of suggesting things in a way that does not
> break backwards compatibility, but one should attempt to make the distinction
> between "changing something which was broken in order to get to something
> reasonable" and "changing something reasonable into something broken".
Don't shoot the messenger! :)
I was pretty confused by it too, especially since I do LOTS of display
jumping. After failing some of this jumping, I finally typed the
command at the prompt and got a strange response. So I read the
manpage. It's all there. I couldn't say why, but I had too many other
fish to fry to bother saying anything then.
It's probably not the only deprecation or interface change from 4.x. I
believe the 'nslookup' tool is now a wrapper to the 'host' utility, but
I never used either one in complex enough ways to see any
incompatibility. I can't quite remember, but I have the feeling there
was another gotcha I had to get used to going to 5.x.
Oh well, I still like 5.3 better for some reason. Maybe it's just the
awesome machine I've got it running on though . . .
Lou
--
Louis LeBlanc FreeBSD-at-keyslapper-DOT-net
Fully Funded Hobbyist, KeySlapper Extrordinaire :)
This is a list only address, and the return address is a black hole!
Send off-list email to: leblanc at keyslapper d.t net
Key fingerprint = C5E7 4762 F071 CE3B ED51 4FB8 AF85 A2FE 80C8 D9A2
Kent's Heuristic:
Look for it first where you'd most like to find it.
--Fig2xvG2VGoz8o/s
Content-Type: application/pgp-signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (FreeBSD)
iD8DBQFCAVHLr4Wi/oDI2aIRAv2RAJsFOSOepfH2xC8eIgtoxfAci5wgRwCfZz3Y
D98GSRMnartgfJqd364MDCc=
=/Jvt
-----END PGP SIGNATURE-----
--Fig2xvG2VGoz8o/s--
Chuck Swiger
> Don't shoot the messenger! :)
Heh, sorry, that wasn't my intention.
[ ... ]
> It's probably not the only deprecation or interface change from 4.x. I
> believe the 'nslookup' tool is now a wrapper to the 'host' utility, but
> I never used either one in complex enough ways to see any
> incompatibility. I can't quite remember, but I have the feeling there
> was another gotcha I had to get used to going to 5.x.
nslookup being depreciated was actually announced, and a version (or several?)
which gave a warning to use something else but otherwise worked fine were
released over the course of a year or two, and *then* the program got changed.
Gert Cuykens
non-network local connections being added to access control list
I#
ok that seems to work a bit better meaning i dont get the message "can
not start screen saver deamon bl bla bla....." Instead i get a message
in my log that locking is not enabled ?
Louis LeBlanc
--llIrKcgUOe3dCx0c
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
On 02/02/05 11:36 PM, Gert Cuykens sat at the `puter and typed:
> I# xhost local:
> non-network local connections being added to access control list
> I#
>
> ok that seems to work a bit better meaning i dont get the message "can
> not start screen saver deamon bl bla bla....." Instead i get a message
> in my log that locking is not enabled ?
Doesn't ring any bells. What log, and what is the entry?
Are you still having trouble with xscreensaver?
FTR, I have the following in my ~/.xinitrc and I never have trouble with
xscreensaver - although it is only started after this command - by the
wm.
Lou
--
Louis LeBlanc FreeBSD-at-keyslapper-DOT-net
Fully Funded Hobbyist, KeySlapper Extrordinaire :)
This is a list only address, and the return address is a black hole!
Send off-list email to: leblanc at keyslapper d.t net
Key fingerprint = C5E7 4762 F071 CE3B ED51 4FB8 AF85 A2FE 80C8 D9A2
"Contrariwise," continued Tweedledee, "if it was so, it might be, and if
it were so, it would be; but as it isn't, it ain't. That's logic!"
-- Lewis Carroll, "Through the Looking Glass"
--llIrKcgUOe3dCx0c
Content-Type: application/pgp-signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (FreeBSD)
iD8DBQFCAVeKr4Wi/oDI2aIRAknWAKCMOivzTR3wfHrNh68mD0kfzAadEACfZb5+
O9NBUCQQS1McIr09QaJH21w=
=Dj1r
-----END PGP SIGNATURE-----
--llIrKcgUOe3dCx0c--
Chris Hodgins
> I# xhost local:
> non-network local connections being added to access control list
> I#
>
> ok that seems to work a bit better meaning i dont get the message "can
> not start screen saver deamon bl bla bla....." Instead i get a message
> in my log that locking is not enabled ?
> freebsd-...@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-questions
> To unsubscribe, send any mail to "freebsd-questi...@freebsd.org"
>
When I configure xscreensaver I use the xscreensaver-demo command. This
allows you to set everything up for that user and start and stop the
xscreensaver daemon. You run this as the local user.
There is a way to cheat xhosting as root if you are not running
remotely. If you simply use "su" instead of "su -" it should keep all
the environment including the DISPLAY setup correctly. This seems to
work well for me.
Generally I do this to xhost from root to my user display.
$ xhost local:
$ su -
Password:
# bash
# export DISPLAY=:0
# gcalctool
HTH
Chris
Louis LeBlanc
--TB36FDmn/VVEgNH/
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
On 02/03/05 12:05 AM, Gert Cuykens sat at the `puter and typed:
> On Wed, 2 Feb 2005 17:43:23 -0500, Louis LeBlanc <Fre...@keyslapper.net>=
wrote:
> > On 02/02/05 11:36 PM, Gert Cuykens sat at the `puter and typed:
> > > I# xhost local:
> > > non-network local connections being added to access control list
> > > I#
> > >
> > > ok that seems to work a bit better meaning i dont get the message "can
> > > not start screen saver deamon bl bla bla....." Instead i get a message
> > > in my log that locking is not enabled ?
> >=20
> > Doesn't ring any bells. What log, and what is the entry?
> >=20
> > Are you still having trouble with xscreensaver?
> >=20
>=20
> My xscreensaver is telling me "running in root not allowed" my root
> needs a pretty screensaver too you know grrrr
>=20
> So how do i enable a root screen saver ?
I assume this refers to the root window. Surely you're not logged
into X as root.
Try this:
check your DISPLAY environment variable with
echo $DISPLAY
make sure it's ':0.0' or something similar, like <hostname>:0.0, then
run this:
/usr/X11R6/bin/xscreensaver -display $DISPLAY &
That should do what you're trying to do.
Lou
--=20
Louis LeBlanc FreeBSD-at-keyslapper-DOT-net
Fully Funded Hobbyist, KeySlapper Extrordinaire :)
Key fingerprint =3D C5E7 4762 F071 CE3B ED51 4FB8 AF85 A2FE 80C8 D9A2
It is much easier to suggest solutions when you know nothing about the prob=
lem.
--TB36FDmn/VVEgNH/
Content-Type: application/pgp-signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (FreeBSD)
iD8DBQFCAWa+r4Wi/oDI2aIRAi1BAJ4xwbLvzI3B+DuwDJGmtCt9F9S+fgCfRm1F
Q5SFf6zb2PoqGPC3BuG7SJU=
=FQCZ
-----END PGP SIGNATURE-----
--TB36FDmn/VVEgNH/--
Gert Cuykens
>
>
> On 2/3/2005 at 00:05 Gert Cuykens wrote:
>
> >On Wed, 2 Feb 2005 17:43:23 -0500, Louis LeBlanc
> <Fre...@keyslapper.net>
> >> On 02/02/05 11:36 PM, Gert Cuykens sat at the `puter and typed:
> >> > I# xhost local:
> >> > non-network local connections being added to access control list
> >> > I#
> >> >
> >> > ok that seems to work a bit better meaning i dont get the message
> "can
> >> > not start screen saver deamon bl bla bla....." Instead i get a
> message
> >> > in my log that locking is not enabled ?
> >>
> >>
> >>
> >
> >needs a pretty screensaver too you know grrrr
> >
>
> savers are only needed when a CRT will be on (Wasting 100 watts while
> nobody is looking, it adds up to about $.10/day), for long periods of
> time at a screen that is otherwise unchanging over several years. The
> only burn in I've ever seen is a log in screen, normal users change
> enough on their display that burn-in isn't a problem.
>
> Root should NEVER log in except when the system is single user, or
> fresh install. In both cases that is command line only. If you must
> use some graphical config tool, su from some other user. As a last
> resort you could log in as root, but even then you should do the job
> and than log off fast, before you make a mistake!
>
> Programs like xscreensaver are doing FreeBSD a favor by preventing
> people from running as Administrator. A significant number of
> problems people have with Ms Windows is because users run as
> administrator by default. When programs like xscreensaver detect that
> you are root and refuse to run it makes it that much less likely that
> you will make a mistake while running as root. Mistakes when you are
> a normal user are bad enough, mistakes as root are worse.
>
> xscreensaver is also saving themselves in another way, if there is a
> unexpected bug that is exploitable, by refusing to run as root they can
> at least ensure that your whole system isn't compromised. This is
> particularly a big deal for xscreensaver where you can expect nobody
> will be around to watch evil people from attempting to break your
> system.
>
> If all that isn't enough to convince you otherwise: the source is
> there. Modify it yourself.
>
And still i think the user should be able to make that desision and
not xscreensaver, it is against the constitution namely freedome of
screensaver :P
Gert Cuykens
> into X as root.
no i am just logged as a user into X and my user name is the same as
root :) Lets call it the user root window.
> Try this:
> check your DISPLAY environment variable with
> echo $DISPLAY
> make sure it's ':0.0' or something similar, like <hostname>:0.0, then
> run this:
> /usr/X11R6/bin/xscreensaver -display $DISPLAY &
>
> That should do what you're trying to do.
>
> Lou
> --
I# /usr/X11R6/bin/xscreensaver -display $DISPLAY
xscreensaver: 01:02:41: locking is disabled (running as nobody).
xscreensaver: 01:02:41: locking only works when xscreensaver is launched
by a normal, non-privileged user (e.g., not "root".)
See the manual for details.
man the xscreensaver thingie isnt kidding about it...
Chris Hodgins
Don't want to be rude but do you have a specific reason for running
xscreensaver as root?
Chris
Louis LeBlanc
--ghzN8eJ9Qlbqn3iT
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On 02/03/05 01:10 AM, Gert Cuykens sat at the `puter and typed:
> > I assume this refers to the root window. Surely you're not logged
> > into X as root.
>=20
> no i am just logged as a user into X and my user name is the same as
> root :) Lets call it the user root window.
>=20
> > Try this:
> > check your DISPLAY environment variable with
> > echo $DISPLAY
> > make sure it's ':0.0' or something similar, like <hostname>:0.0, then
> > run this:
> > /usr/X11R6/bin/xscreensaver -display $DISPLAY &
> >=20
> > That should do what you're trying to do.
> >=20
> > Lou
> > --
>=20
> I# /usr/X11R6/bin/xscreensaver -display $DISPLAY
> xscreensaver: 01:02:41: locking is disabled (running as nobody).
> xscreensaver: 01:02:41: locking only works when xscreensaver is launched
> by a normal, non-privileged user (e.g., not "root".)
> See the manual for details.
>=20
> man the xscreensaver thingie isnt kidding about it...
That's your whole problem. It is widely considered a Very Bad Thing
to log into X as root. Xscreensaver refuses to run there because it
calls external programs, which it gives free reign within it's access
limitations. If xscreensaver were running as root, these extermal
programs would therefore run as root, and should any of them be
written with certain malicious, or even just errant code, your secure
box could do anything from implode due to a bad disk access in the
boot sector, to hang it's kiester right out the internet for all to
see and poke and prod. And they WILL poke and prod.
xscreensaver is the only such program that comes to mind that tries to
protect you in this way, but think of all the other programs you run:
your wm, all those utilities, the calculator, and the list goes on.
Not all of these are part of the OS, most are "contrib" code, which
means they were written by people outside the official team for
whatever project you got it with. That doesn't mean it's not good
code, most of it is excellent at the very least, but it doesn't always
have the same rigorous testing cycle, and it is almost NEVER written
to run as root. And a process intended to run as root DOES get
structured differently.
I *VERY* strongly recommend you create a real user, call it gert or
cuykens, or the name of your box, or whatever you want and DON'T add
it to every group and give it admin privileges. Using root for
anything but administrative use or accessing restricted resources is a
huge security hole.
Cheers.
Lou
--=20
Louis LeBlanc FreeBSD-at-keyslapper-DOT-net
Fully Funded Hobbyist, KeySlapper Extrordinaire :)
Key fingerprint =3D C5E7 4762 F071 CE3B ED51 4FB8 AF85 A2FE 80C8 D9A2
Secretary's Revenge:
Filing almost everything under "the".
--ghzN8eJ9Qlbqn3iT
Content-Type: application/pgp-signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (FreeBSD)
iD8DBQFCAXevr4Wi/oDI2aIRAphcAJ43bwc9FfbFsrCCrWDWYNwjp0s9nwCeL+Lj
3Z+FKRZjEivcx+wIxXTHOks=
=xn6a
-----END PGP SIGNATURE-----
--ghzN8eJ9Qlbqn3iT--
Gert Cuykens
> xscreensaver as root?
>
> Chris
Well the reason is very simple actuale lets pretend we have a user
gert. User gert has alot of pictures and music stuff phone numbers
user gert dont want does things to be gone. Somebody hacks user gert
because user gert uses a screensaver. And the hacker deletes all
files. User gert is not happy because he lost everything. Do you think
user gert gives a chit that the system was untouched because the
hacker did not had root permission ?
For me its wrong to think user accounts are not importend because they
do for the average window xp single user. They dont care about viruses
infection on there system reinstalling everything they care about
there files. So if sreensaver is a securty risc as root i doesnt mean
its not a security risck for a user account. The only differens
between a root and user should be that users can not read or mess with
other users files. The security sould be EXACTLY the same. So if root
can not run a screensaver then the users can also not run a
screensaver.
Louis LeBlanc
--C7zPtVaVf+AK4Oqc
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
On 02/03/05 03:19 AM, Gert Cuykens sat at the `puter and typed:
> > Don't want to be rude but do you have a specific reason for running
> > xscreensaver as root?
> >=20
> > Chris
>=20
> Well the reason is very simple actuale lets pretend we have a user
> gert. User gert has alot of pictures and music stuff phone numbers
> user gert dont want does things to be gone. Somebody hacks user gert
> because user gert uses a screensaver. And the hacker deletes all
> files. User gert is not happy because he lost everything. Do you think
> user gert gives a chit that the system was untouched because the
> hacker did not had root permission ?
You've made backups, right? That would be the standard method of
protecting these files. Trust me, EVERY other person on this list has
files they value above their system. The system is ALWAYS easier to
restore than lost data. The problem is that with root permission, a
hacker can do a LOT more damage than just *your system*, and with
root, it is pretty trivial to cover their tracks so that when the men
in black come to your door and ask to see your computer logs, it looks
like you're the one that's been trying to hack the NSA. Then you'd
care if they had root access.
> For me its wrong to think user accounts are not importend because they
> do for the average window xp single user. They dont care about viruses
> infection on there system reinstalling everything they care about
> there files. So if sreensaver is a securty risc as root i doesnt mean
> its not a security risck for a user account. The only differens
> between a root and user should be that users can not read or mess with
> other users files. The security sould be EXACTLY the same. So if root
> can not run a screensaver then the users can also not run a
> screensaver.
There's a lot more to system security than virus protection. There's
secure passwords, restriction of root access, backups, firewalls, and
a lot more. The fact that Windows often has to provide authoritative
access to all users has been one of it's biggest vulnerabilities to
virii. If everyone on *nix systems had administration privileges,
you'd probably see quite a few worms working their way around these
systems. And FTR, nobody can even frickin' PRINT to a NETWORK printer
in XP without admin privs! How *stupid* is that!?
My advice, get a backup process going and use a non root account.
Lock down root, and use secure passwords. You can restrict access to
any user account in a number of ways. I have some accounts with
abysmally simple passwords, but they aren't allowed to log in
non-locally in any way, shape or form. The only one that is, is quite
limited to how and from where it can log in, and it uses a reasonably
secure password.
Is my system "secure"? Well, to a pretty good extent, I think it is.
Secure enough to make it not worth the effort to your average to
moderately savvy cracker. More so than I've made it in the past at
any rate. I still watch closely for any signs of attempts, and deal
with those I think are worthy of attention, but I don't worry so much
now.
That's basic admin, isn't it guys?
I'm sure there will be a few additions to this, and possibly even a
more organized listing of best practices, but I'm too tired to find
the list right now - it's probably right there in the handbook anyway.
Lou
--=20
Louis LeBlanc FreeBSD-at-keyslapper-DOT-net
Fully Funded Hobbyist, KeySlapper Extrordinaire :)
Key fingerprint =3D C5E7 4762 F071 CE3B ED51 4FB8 AF85 A2FE 80C8 D9A2
Begathon, n.:
A multi-day event on public television, used to raise money so
you won't have to watch commercials.
--C7zPtVaVf+AK4Oqc
Content-Type: application/pgp-signature
Content-Disposition: inline
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (FreeBSD)
iD8DBQFCAawXr4Wi/oDI2aIRAobgAJ9XPdEqXBfOftm1h1vzgQFNU3sZ+wCdGKrs
+GoWBOPCAv5bsJ6hJ4wXEPw=
=mFgE
-----END PGP SIGNATURE-----
--C7zPtVaVf+AK4Oqc--
Ted Mittelstaedt
> -----Original Message-----
> From: owner-freeb...@freebsd.org
> [mailto:owner-freeb...@freebsd.org]On Behalf Of Gert Cuykens
> Sent: Wednesday, February 02, 2005 6:20 PM
> To: Chris Hodgins
> Cc: freebsd-...@freebsd.org
> Subject: Re: xhost +localhost
>
>
> > Don't want to be rude but do you have a specific reason for running
> > xscreensaver as root?
> >
> > Chris
>
> Well the reason is very simple actuale lets pretend we have a user
> gert. User gert has alot of pictures and music stuff phone numbers
> user gert dont want does things to be gone. Somebody hacks user gert
> because user gert uses a screensaver. And the hacker deletes all
> files. User gert is not happy because he lost everything. Do you think
> user gert gives a chit that the system was untouched because the
> hacker did not had root permission ?
>
> For me its wrong to think user accounts are not importend because they
> do for the average window xp single user. They dont care about viruses
> infection on there system reinstalling everything they care about
> there files. So if sreensaver is a securty risc as root i doesnt mean
> its not a security risck for a user account. The only differens
> between a root and user should be that users can not read or mess with
> other users files. The security sould be EXACTLY the same. So if root
> can not run a screensaver then the users can also not run a
> screensaver.
While all of this is very interesting academic, if user Gert is dumb
enough to leave the console of his UNIX system accessible then user
Ted can come along and power cycle it into single user mode and wipe his
disks whether he has the root password or not.
Or, are you assuming that the 'bios' passwords in the typical PC are
immune from 60 seconds of CMOS battery removal?
Ted
Gert Cuykens
Can a non root user shutdown a pc ? PS does your pc have a power cable :)
Rod Person
> i want a screensaver but the ....... xscreensaver daemon wont start
> complaining about acces controle. I did xhost +localhost but it still
> wont start :(
Sounds like your trying to run the screensaver from a root terminal in a=20
normal user session. If so, just run xscreensaver as the user.
=2D-=20
Rod
++++++++++++++++++++++++++++++++++++++++++++++++++++++++
"If you stay the same long enough you'll be in=20
style some day again." =A0Cren Dog=20
++++++++++++++++++++++++++++++++++++++++++++++++++++++++
epilogue
Gert Cuykens <gert.c...@gmail.com> wrote:
> On Thu, 3 Feb 2005 00:32:23 -0800, Ted Mittelstaedt
> <te...@toybox.placo.com> wrote:
> > While all of this is very interesting academic, if user Gert is dumb
> > enough to leave the console of his UNIX system accessible then user
> > Ted can come along and power cycle it into single user mode and wipe
> > his disks whether he has the root password or not.
While i quite agree with Ted's encouraging Gert to run X as joe user,
rather than root (for a variety of security related reasons) it is a
trivial matter implement a password requirement for boot -s. This way,
even if a user can boot -s, they *must* have the root passwd.
This implementation does mean, however, that you should not forget the
root passwd, for if you do forget, you will not be able to reset it
via boot -s and passwd.
/etc/ttys
# If console is marked "insecure", then init will ask for the root
# password when going to single-user mode.
console none unknown off insecure
my 2 cents CAD for the day.
cheers,
epi
Loren M. Lang
> i want a screensaver but the ....... xscreensaver daemon wont start
> complaining about acces controle. I did xhost +localhost but it still
> wont start :(
Adding localhost will allow all programs running on localhost to
connect to the server though TCP to the X server, but local programs
usually use something called unix domain sockets to access services
locally as it's faster than going through TCP sockets. Unix domain
sockets are special files on the harddrive. For display :0, the file is
/tmp/.X11-unix/X0. If you set DISPLAY to localhost:0 instead of :0,
then whatever programs try to access X will connect to localhost on port
6000 + 0, instead of the X0 file in /tmp/.X11-unix. If you can change
the DISPLAY environment variable for xscreensaver then xhost +localhost
will work. The better solution would be to make use the .Xauthority
file is setup correctly instead of using xhost +localhost. This usually
happens automatically, unless your trying to do something very
non-standard. Try setting the variable XAUTHORITY to
/home/username/.Xauthority.
> _______________________________________________
> freebsd-...@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-questions
> To unsubscribe, send any mail to "freebsd-questi...@freebsd.org"
--
I sense much NT in you.
NT leads to Bluescreen.
Bluescreen leads to downtime.
Downtime leads to suffering.
NT is the path to the darkside.
Powerful Unix is.
Public Key: ftp://ftp.tallye.com/pub/lorenl_pubkey.asc
Fingerprint: B3B9 D669 69C9 09EC 1BCD 835A FAF3 7A46 E4A3 280C
Loren M. Lang
> Louis LeBlanc wrote:
> >>i want a screensaver but the ....... xscreensaver daemon wont start
> >>complaining about acces controle. I did xhost +localhost but it still
> >>wont start :(
> >
> >like this:
> >
> >xhost local:
> >
> >Exactly as typed above.
>
> Please tell me you are joking.
This enable all programs to have access that are using unix domain
sockets to not need the MIT-MAGIC-COOKIE stored in the .Xauthority file
in the users home directory so any user can open a program on that
display. xhost +localhost adds all programs from localhost using tcp
connections instead. DISPLAY=:0 causes a program to use fast unix
domain sockets where DISPLAY=localhost:0 causes a program to use slow
tcp sockets instead. tcp sockets are really only needed for remote
connections and xhost +localhost won't allow any local programs to
access X unless they use tcp, not unix. See my first response for more
information.
>
> I remember learning to use "xhost +" in 1989 or '90 on X11--, before the
> command improved to take hostnames as arguments to control which
> connections were allowed and which should be refused on a per-host basis.
> At the time, there were so few machines running X that malicious X
> connections were not a significant concern.
>
> Having "xhost +localhost" work the same way as "xhost +foo.cmu.edu"-- to
> avoid treating the local host as a special case-- was a good idea fifteen
> years ago.
>
> I do not have a perfect record of suggesting things in a way that does not
> break backwards compatibility, but one should attempt to make the
> distinction between "changing something which was broken in order to get to
> something reasonable" and "changing something reasonable into something
> broken".
>
> --
> -Chuck
Gert Cuykens
> This enable all programs to have access that are using unix domain
> sockets to not need the MIT-MAGIC-COOKIE stored in the .Xauthority file
> in the users home directory so any user can open a program on that
> display. xhost +localhost adds all programs from localhost using tcp
> connections instead. DISPLAY=:0 causes a program to use fast unix
> domain sockets where DISPLAY=localhost:0 causes a program to use slow
> tcp sockets instead. tcp sockets are really only needed for remote
> connections and xhost +localhost won't allow any local programs to
> access X unless they use tcp, not unix. See my first response for more
> information.
ok time out :)
1)does xhost set the DISPLAY variable ?
2)does xhost local: also uses the tcp thingie or use it the x socket thingie ?
3)what must i put in the .Xauthority file to make the screensaver work
with having to use xhost ?
Chris Hodgins
> On Thu, 3 Feb 2005 14:43:39 +0100
> Gert Cuykens <gert.c...@gmail.com> wrote:
>
>
>>On Thu, 3 Feb 2005 00:32:23 -0800, Ted Mittelstaedt
>><te...@toybox.placo.com> wrote:
>
>
>>>While all of this is very interesting academic, if user Gert is dumb
>>>enough to leave the console of his UNIX system accessible then user
>>>Ted can come along and power cycle it into single user mode and wipe
>>>his disks whether he has the root password or not.
>
>
> While i quite agree with Ted's encouraging Gert to run X as joe user,
> rather than root (for a variety of security related reasons) it is a
> trivial matter implement a password requirement for boot -s. This way,
> even if a user can boot -s, they *must* have the root passwd.
>
> This implementation does mean, however, that you should not forget the
> root passwd, for if you do forget, you will not be able to reset it
> via boot -s and passwd.
>
> /etc/ttys
>
> # If console is marked "insecure", then init will ask for the root
> # password when going to single-user mode.
>
> console none unknown off insecure
>
> my 2 cents CAD for the day.
>
>
> cheers,
> epi
> freebsd-...@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-questions
> To unsubscribe, send any mail to "freebsd-questi...@freebsd.org"
>
If you have local access to a machine, you can easily get
access...password or not.
Chris
Chris Hodgins
> On Thu, 3 Feb 2005 14:58:35 -0800, Loren M. Lang <lor...@alzatex.com> wrote:
>
>>This enable all programs to have access that are using unix domain
>>sockets to not need the MIT-MAGIC-COOKIE stored in the .Xauthority file
>>in the users home directory so any user can open a program on that
>>display. xhost +localhost adds all programs from localhost using tcp
>>connections instead. DISPLAY=:0 causes a program to use fast unix
>>domain sockets where DISPLAY=localhost:0 causes a program to use slow
>>tcp sockets instead. tcp sockets are really only needed for remote
>>connections and xhost +localhost won't allow any local programs to
>>access X unless they use tcp, not unix. See my first response for more
>>information.
>
>
> ok time out :)
> 1)does xhost set the DISPLAY variable ?
No. You have export the variable yourself. xhost allows you to grant
or deny access to others. A user who has access and wishes to connect
may set his DISPLAY variable to the corresponding DISPLAY.
> 2)does xhost local: also uses the tcp thingie or use it the x socket thingie ?
I think xhost local: allows access to BSD sockets, so not tcp.
> 3)what must i put in the .Xauthority file to make the screensaver work
> with having to use xhost ?
Gert Cuykens
<chod...@cis.strath.ac.uk> wrote:
> Gert Cuykens wrote:
> > On Thu, 3 Feb 2005 14:58:35 -0800, Loren M. Lang <lor...@alzatex.com> wrote:
> >
> >>This enable all programs to have access that are using unix domain
> >>sockets to not need the MIT-MAGIC-COOKIE stored in the .Xauthority file
> >>in the users home directory so any user can open a program on that
> >>display. xhost +localhost adds all programs from localhost using tcp
> >>connections instead. DISPLAY=:0 causes a program to use fast unix
> >>domain sockets where DISPLAY=localhost:0 causes a program to use slow
> >>tcp sockets instead. tcp sockets are really only needed for remote
> >>connections and xhost +localhost won't allow any local programs to
> >>access X unless they use tcp, not unix. See my first response for more
> >>information.
> >
> >
> > ok time out :)
> > 1)does xhost set the DISPLAY variable ?
>
> No. You have export the variable yourself. xhost allows you to grant
> or deny access to others. A user who has access and wishes to connect
> may set his DISPLAY variable to the corresponding DISPLAY.
>
> > 2)does xhost local: also uses the tcp thingie or use it the x socket thingie ?
>
> I think xhost local: allows access to BSD sockets, so not tcp.
>
thx
3)what must i put in the .Xauthority file to make the screensaver work
without having to use xhost local:?
Loren M. Lang
> On Thu, 3 Feb 2005 14:43:39 +0100
> Gert Cuykens <gert.c...@gmail.com> wrote:
>
> > On Thu, 3 Feb 2005 00:32:23 -0800, Ted Mittelstaedt
> > <te...@toybox.placo.com> wrote:
>
> > > While all of this is very interesting academic, if user Gert is dumb
> > > enough to leave the console of his UNIX system accessible then user
> > > Ted can come along and power cycle it into single user mode and wipe
> > > his disks whether he has the root password or not.
>
> While i quite agree with Ted's encouraging Gert to run X as joe user,
> rather than root (for a variety of security related reasons) it is a
> trivial matter implement a password requirement for boot -s. This way,
> even if a user can boot -s, they *must* have the root passwd.
Well, with the bit about removing the cmos battery, I think he was also
getting at changing the bios so that other boot media like floppies or
cds can be used, then what good is a root password?
<snip>
> my 2 cents CAD for the day.
>
>
> cheers,
> epi
> _______________________________________________
> freebsd-...@freebsd.org mailing list
> http://lists.freebsd.org/mailman/listinfo/freebsd-questions
> To unsubscribe, send any mail to "freebsd-questi...@freebsd.org"
--
I sense much NT in you.
NT leads to Bluescreen.
Bluescreen leads to downtime.
Downtime leads to suffering.
NT is the path to the darkside.
Powerful Unix is.
Public Key: ftp://ftp.tallye.com/pub/lorenl_pubkey.asc
Fingerprint: B3B9 D669 69C9 09EC 1BCD 835A FAF3 7A46 E4A3 280C
Gert Cuykens
For the love of god please dont do that meaning passwords get lost and
single user mode is just fine the way it is.
Loren M. Lang
> On Thu, 3 Feb 2005 14:58:35 -0800, Loren M. Lang <lor...@alzatex.com> wrote:
> > This enable all programs to have access that are using unix domain
> > sockets to not need the MIT-MAGIC-COOKIE stored in the .Xauthority file
> > in the users home directory so any user can open a program on that
> > display. xhost +localhost adds all programs from localhost using tcp
> > connections instead. DISPLAY=:0 causes a program to use fast unix
> > domain sockets where DISPLAY=localhost:0 causes a program to use slow
> > tcp sockets instead. tcp sockets are really only needed for remote
> > connections and xhost +localhost won't allow any local programs to
> > access X unless they use tcp, not unix. See my first response for more
> > information.
>
> ok time out :)
> 1)does xhost set the DISPLAY variable ?
No, in fact, xhost needs the DISPLAY variable already set so that it
knows which display to try and connect to to change access control.
xhost needs some way to authenticate itself to the X server so X can
trust that it's a legit user trying to change the access control. If
you open up X to all local users by using something like xhost
+localhost or xhost local: then any local user could take over your
display and use xhost to disable your access to it.
> 2)does xhost local: also uses the tcp thingie or use it the x socket thingie ?
local: allows anyone to access the X server through unix domain sockets.
+localhost allows all local programs to access X though tcp sockets.
Normally tcp sockets are only used for remote connections since they are
slower than unix sockets, but unix sockets only work on the same
machine.
> 3)what must i put in the .Xauthority file to make the screensaver work
> with having to use xhost ?
When X first logs in to a user, it creates the .Xauthority file in that
users home directory and fills it with a random string called a
MIT-MAGIC-COOKIE. Any X client, by default, reads that file to see what
the cookie is then sends it to the X server to authenticate itself.
Anyone who can read that file can access the display so that file is
normally only readable by the user who logged in, though root can always
read it because root is god. When you run an X program as a different
user, it will look in that users home directory for the .Xauthority
file and so won't be able to find the right cookie unless you used the
xauth command to give that user the cookie ahead of time. By setting
the XAUTHORITY environment variable to some other file, it will check that
file for the magic cookie instead of the current users home directory.
This is useful when running a command as root that you want to access a
normal users X server. This is a much more secure way to allow access
to X than using xhost since you know what users are able to access X,
not just which computers, which may have multiple users on them.
In summary, don't touch xhost, just use:
XAUTHORITY=/home/user/.Xauthority xscreensaver
or you can use xauth to extract the magic cookie and then import it into
the correct users .Xauthority file. As the user of the X server:
xauth extract my-cookie-file $DISPLAY
Saves the magic cookie to a file called my-cookie-file for the current
display. Then as the user who want to access the X display:
xauth merge my-cookie-file
Adds the cookie stored in my-cookie file to the current users
.Xauthority file. Now user B can open an X application on A's X server.
Oh, and don't run xscreensaver as root EVER! Instead, if you're really
paranoid about security, make a user who can access any of your files
whose sole purpose is to run xscreensaver then use that user to run it.
This is still not that much more secure since any user that can access
an X server can essentially take it over and control your mouse and
keyboard doing what ever they want, like openning an xterm on your
display and running the passwd command to change your passwd. Now they
just gained access to all your files as well.
Gert Cuykens
Thx this clears alot of questions :)
One more question doh, about the x cookie.
How long does it take to calculate the x cookie string yourself of a
user you want to hack :)
Gert Cuykens
> One more question doh, about the x cookie.
>
> How long does it take to calculate the x cookie string yourself of a
> user you want to hack :)
>
PS is the x cookie in anyway related to the user passwd ?
Loren M. Lang
> > Thx this clears alot of questions :)
> > One more question doh, about the x cookie.
> >
> > How long does it take to calculate the x cookie string yourself of a
> > user you want to hack :)
> >
>
> PS is the x cookie in anyway related to the user passwd ?
Completely unrelated, it's just a random number basicly.
--
I sense much NT in you.
NT leads to Bluescreen.
Bluescreen leads to downtime.
Downtime leads to suffering.
NT is the path to the darkside.
Powerful Unix is.
Public Key: ftp://ftp.tallye.com/pub/lorenl_pubkey.asc
Fingerprint: B3B9 D669 69C9 09EC 1BCD 835A FAF3 7A46 E4A3 280C
Gert Cuykens
> > PS is the x cookie in anyway related to the user passwd ?
>
> Completely unrelated, it's just a random number basicly.
>
If it is a random number how can the xserver it user x random number
and not user y random number ?
Loren M. Lang
> On Sun, 6 Feb 2005 02:05:00 -0800, Loren M. Lang <lor...@alzatex.com> wrote:
> > > PS is the x cookie in anyway related to the user passwd ?
> >
> > Completely unrelated, it's just a random number basicly.
> >
>
> If it is a random number how can the xserver it user x random number
> and not user y random number ?
When the X server is first started a 128 bit binary number is generated
and stored in a file .Xauthority which is created in a users home
directory and made to be readable only by that user. The X server read
the file on startup and, by default, only allows clients to connect that
know that magic number. You can give that magic number to other people
and allow them to connect using the xauth program. Every time the X
server is started a new number is generated and it used instead so
knowing what number was used last time the user logged in won't be
useful anymore. It's pure chance that two users won't have the same
magic number at the same time, AFAIK, but with 2^128 possibilities, it's
EXTREMELY unlikely.
--
I sense much NT in you.
NT leads to Bluescreen.
Bluescreen leads to downtime.
Downtime leads to suffering.
NT is the path to the darkside.
Powerful Unix is.
Public Key: ftp://ftp.tallye.com/pub/lorenl_pubkey.asc
Fingerprint: B3B9 D669 69C9 09EC 1BCD 835A FAF3 7A46 E4A3 280C