On Wednesday 05 August 2009 19:42:54 Anthony Sorace wrote:
/sys/log/cron: rc (cpurc): can't open: 'sys/log/cron' is a directory
... not quite sure what to make of that.
that's weird. it shouldn't be a directory, just an append-only file
like most of the others in /sys/log. not sure how it
This will create a n append only file, not a directory. The usual way to
initialised cron for a user is auth/cron -c (similarly for mail type mail -c)
when you have first logged in as that user.
if you run /sys/lib/newuser when you first login (i.e. the very first time, do
this only once) then
On Monday 10 August 2009 03:33:04 Steve Simon wrote:
This will create a n append only file, not a directory. The usual way to
initialised cron for a user is auth/cron -c (similarly for mail type mail
-c) when you have first logged in as that user.
if you run /sys/lib/newuser when you first
On Monday 10 August 2009 09:01:39 ron minnich wrote:
main: create /active/cron/bootes bootes bootes d775
This is right. It's supposed to be a directory.
cpu% ls -l /cron/bootes
--rw-r--r-- M 9758 bootes bootes 0 Sep 17 2008 /cron/bootes/cron
main: create /active/sys/log/cron bootes
I wonder whether 'auth/cron -c' is the culprit, when I first run
'/sys/lib/newuser' for bootes.
no sense wondering. read the source. /sys/src/cmd/auth/cron.c
you could also use trump to trace the calls.
- erik
On Aug 7, 2009, at 10:08 PM, lu...@proxima.alt.za wrote:
Story time. :)
You're also falling into the trap of believing that because it _can_
happen, it has to happen (Murphy's Law). It punishes the many for the
sins of the few and is a very poor foundation for progress.
It wasn't a
...by the curmudgeonly 9fans...
For those who follow British comedy:
Father Jack, my alter ego!
Others may find this enlightening
http://www.youtube.com/watch?v=kHiDhERvJ4I
-Steve
You should be able to hack /sys/src/cmd/init.c to make it start
whatever you want after booting, based on init(8), but I haven't tried
it. The man page says it prompts for a password on the cpu server, but
that doesn't happen; the source has a pass function but it's not
called anywhere.
it
On Thu, 6 Aug 2009 11:33:18 +0100
Steve Simon st...@quintile.net wrote:
I cannot imageine the senario where random people will have access
to the cpu/auth/file server's consoles. It just doesn't happen
if you are serious about security.
However if you want to protect your console against
On Thu, 6 Aug 2009 22:50:33 -0400
Anthony Sorace ano...@gmail.com wrote:
this is silly. the philosophy has been explained. several people have
given lots of real world usage where it holds up just fine. i'd go
as far as to say the vast majority of plan9 installations are in such
environments.
On Fri, 7 Aug 2009 09:29:25 -0300
Iruata Souza iru.mu...@gmail.com wrote:
On Fri, Aug 7, 2009 at 9:05 AM, Ethan Grammatikidiseeke...@fastmail.fm
wrote:
On Thu, 6 Aug 2009 11:33:18 +0100
Steve Simon st...@quintile.net wrote:
I cannot imageine the senario where random people will have
On Fri, Aug 7, 2009 at 9:39 AM, Ethan Grammatikidiseeke...@fastmail.fm wrote:
On Fri, 7 Aug 2009 09:29:25 -0300
Iruata Souza iru.mu...@gmail.com wrote:
On Fri, Aug 7, 2009 at 9:05 AM, Ethan Grammatikidiseeke...@fastmail.fm
wrote:
On Thu, 6 Aug 2009 11:33:18 +0100
Steve Simon
On Fri, 7 Aug 2009 10:02:27 -0300
Iruata Souza iru.mu...@gmail.com wrote:
On Fri, Aug 7, 2009 at 9:39 AM, Ethan Grammatikidiseeke...@fastmail.fm
wrote:
On Fri, 7 Aug 2009 09:29:25 -0300
Iruata Souza iru.mu...@gmail.com wrote:
On Fri, Aug 7, 2009 at 9:05 AM, Ethan
Ethan wrote:
// Oh God, not the everyday examples == proof argument, PLEASE.
Er, what? everyday examples are a perfectly good existence proof,
which is all they're being used for here. You seem to be after a more
universal correctness sort of proof, for which they're entirely
inappropriate, but
no password protection will suffice when ethics fails.
iru
English Lit grads please avert your eyes...
Something there is that doesn’t love a wall…
He says again, “Good fences make good neighbors.”
-Robert Frost, from Mending Wall
_Something There is That Needs a Wall_
Now here's the point. I and a billion other people HAVE MORE FUN THINGS TO
DO THAN FRET ABOUT SECURITY. A weak OS needs me to put in boring work...
Hah... yes, that would be why I'm merely reading this thread instead of
adding to it... Oh crap, nevermind :-)
--
Ethan Grammatikidis
Story time. :)
You're also falling into the trap of believing that because it _can_
happen, it has to happen (Murphy's Law). It punishes the many for the
sins of the few and is a very poor foundation for progress.
Plan 9 has a good balance of cost of security against eventual real
protection
The Plan 9 way of thinking (wrt the security of physical terminal access)
completely undermines, or somehow fails to recognize, the very real fact
that there is always a cost/risk effort/reward equation at play.
Sure, but you used this against Plan 9 when you should have used it as
a stimulus
On Wednesday 05 August 2009 19:42:54 Anthony Sorace wrote:
/sys/log/cron: rc (cpurc): can't open: 'sys/log/cron' is a directory
... not quite sure what to make of that.
that's weird. it shouldn't be a directory, just an append-only file
like most of the others in /sys/log. not sure how it
On Wed, Aug 5, 2009 at 11:15 PM, Coreyco...@bitworthy.net wrote:
On Wednesday 05 August 2009 19:42:54 Anthony Sorace wrote:
* I hope I don't get beat up on this one (well, I hope I don't get too
beat up on _any_ of these questions...), but it seems strange that
something as important as a
I imagine this is probably a subject full of landmines, so I don't want to
start a war! I won't press the issue, just want to respond to this, and
then I'll just leave the status quo well enough alone.
I respect those opinions which differ from my own.
On Wednesday 05 August 2009 23:30:38 John
On Thu, Aug 6, 2009 at 8:52 AM, Corey co...@bitworthy.net wrote:
I imagine this is probably a subject full of landmines, so I don't want to
start a war! I won't press the issue, just want to respond to this, and
then I'll just leave the status quo well enough alone.
I respect those
I cannot imageine the senario where random people will have access
to the cpu/auth/file server's consoles. It just doesn't happen
if you are serious about security.
However if you want to protect your console against your friends
I wrote a script to do it /n/sources/contrib/steve/rc/conslock
you
Works like a charm. Knowing the the correct manual page(s) to be looking
at certainly helps! grin
I can't help though but be curious as to why there's no command, or
an additional switch to changeuser, to remove users from the keyfile.
I guess due to Plan 9's simplicity motto?
[...]
I
That wasn't a rhetorical question. Why bother locking your door?
Any intruder worth his weight in salt can circumvent such a simple
security mechanism with ease.
[...]
Out of X number of would-be intruders, only a small fraction of those would,
under most circumstances, have the balls and
On Thursday 06 August 2009 01:19:35 Robert Raschke wrote:
On Thu, Aug 6, 2009 at 8:52 AM, Corey co...@bitworthy.net wrote:
snip
That wasn't a rhetorical question. Why bother locking your door?
Any intruder worth his weight in salt can circumvent such a simple
security mechanism with
On Thu, Aug 6, 2009 at 4:28 PM, Coreyco...@bitworthy.net wrote:
On Thursday 06 August 2009 01:19:35 Robert Raschke wrote:
On Thu, Aug 6, 2009 at 8:52 AM, Corey co...@bitworthy.net wrote:
snip
That wasn't a rhetorical question. Why bother locking your door?
Any intruder worth his weight
Short form:
on today's machines, if someone gets physical access, you're owned.
Not much more to say except that with the kind of features vendors
insist on embedding in the systems, you can easily be owned without
physical access -- see the recent Black Hat articles, and I'm not
naming names so
On Aug 6, 2009, at 4:47 AM, erik quanstrom wrote:
Works like a charm. Knowing the the correct manual page(s) to be
looking
at certainly helps! grin
I can't help though but be curious as to why there's no command, or
an additional switch to changeuser, to remove users from the keyfile.
I
On Thursday 06 August 2009 17:01:30 John Floren wrote:
On Thu, Aug 6, 2009 at 4:28 PM, Coreyco...@bitworthy.net wrote:
snip
I honestly can't believe that this is even up for debate! grin
It's just bizarre.
Oh, if we're just protecting against people wandering by who are
obviously there
don't forget to take away the connectors from the power and reset
buttons, otherwise good security concepts;)
It also seems that most of organizations I know have that same kind
of permanency in place even at HR level. If you leave the company
and then get rehired you feel like you've never left -- you badge id
and sorts of HR assigned credentials are simply enabled, not created
anew. Don't know
Incidentially I may use this at home to protect my servers console
against my 2 year old who rather likes keyboards, though this is
a different type of security.
In that situation, the most important security measure it
to place the power switch at an altitude beyond the little
one's reach. I
this is silly. the philosophy has been explained. several people have
given lots of real world usage where it holds up just fine. i'd go
as far as to say the vast majority of plan9 installations are in such
environments.
but regardless, correcting what may be a whole in your environment is
easy;
On Aug 6, 2009, at 6:59 PM, hiro wrote:
don't forget to take away the connectors from the power and reset
buttons, otherwise good security concepts;)
Just out of curiosity, is it possible to simply unbind the console on
one of these servers after bootup in some startup script? Or perhaps
I honestly can't believe that this is even up for debate! grin
It's just bizarre.
It's not. Nothing stops one from putting the extra layer of security
in place, it's just a user-level change, just like it is in Unix to go
from single-user to multi-user mode. The fact that no-one has yet
I have direct experience as a contractor where I have entered
many a co-lo; and was unimpressed with their security to say the least.
I had constant and easy access to a large number of nameless servers,
it's a nobrainer to access keyboard/monitor pairs in many of these places.
That would be
I honestly can't believe that this is even up for debate! grin
It's just bizarre.
It's not. Nothing stops one from putting the extra layer of security
in place, it's just a user-level change, just like it is in Unix to go
from single-user to multi-user mode. The fact that no-one has yet
On Thursday 06 August 2009 21:19:36 lu...@proxima.alt.za wrote:
I have direct experience as a contractor where I have entered
many a co-lo; and was unimpressed with their security to say the least.
I had constant and easy access to a large number of nameless servers,
it's a nobrainer to
On Aug 6, 2009, at 10:19 PM, lu...@proxima.alt.za wrote:
I have direct experience as a contractor where I have entered
many a co-lo; and was unimpressed with their security to say the
least.
I had constant and easy access to a large number of nameless servers,
it's a nobrainer to access
On Thursday 06 August 2009 21:19:05 lu...@proxima.alt.za wrote:
snip
If you think it's worth it, then you need to put your money where your
mouth is.
Like I said:
Anyhow... I guess there's no reason to argue/debate! Looks like I
have some options
... and later:
[...] plus, I've already
On Thu, Aug 6, 2009 at 8:04 PM, Daniel Lyonsfus...@storytotell.org wrote:
On Aug 6, 2009, at 6:59 PM, hiro wrote:
don't forget to take away the connectors from the power and reset
buttons, otherwise good security concepts;)
Just out of curiosity, is it possible to simply unbind the console
Just some scattered random questions I've accrued after successfully
getting a cpu/auth server up and running:
* I'm seeing an error on boot:
/sys/log/cron: rc (cpurc): can't open: 'sys/log/cron' is a directory
... not quite sure what to make of that. I guess I might have done
something wrong
43 matches
Mail list logo
