> 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 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 boot
> 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 bootes a664
This is right. It's supposed to be an append-only
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 firs
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 the
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 s
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 positio
> "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 stim
> 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 used to, but the new security model invalidated that concept: some
of its foundations fell foul of the new design and were discarded.
That w
> 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 a
>
>
>
> 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 Grammat
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_
Somethin
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
On Fri, 7 Aug 2009 10:02:27 -0300
Iruata Souza wrote:
> On Fri, Aug 7, 2009 at 9:39 AM, Ethan Grammatikidis
> wrote:
> > On Fri, 7 Aug 2009 09:29:25 -0300
> > Iruata Souza wrote:
> >
> >> On Fri, Aug 7, 2009 at 9:05 AM, Ethan Grammatikidis
> >> wrote:
> >> > On Thu, 6 Aug 2009 11:33:18 +0100
>
On Fri, Aug 7, 2009 at 9:39 AM, Ethan Grammatikidis wrote:
> On Fri, 7 Aug 2009 09:29:25 -0300
> Iruata Souza wrote:
>
>> On Fri, Aug 7, 2009 at 9:05 AM, Ethan Grammatikidis
>> wrote:
>> > On Thu, 6 Aug 2009 11:33:18 +0100
>> > "Steve Simon" wrote:
>> >
>> >> I cannot imageine the senario where
On Fri, 7 Aug 2009 09:29:25 -0300
Iruata Souza wrote:
> On Fri, Aug 7, 2009 at 9:05 AM, Ethan Grammatikidis
> wrote:
> > On Thu, 6 Aug 2009 11:33:18 +0100
> > "Steve Simon" wrote:
> >
> >> I cannot imageine the senario where random people will have access
> >> to the cpu/auth/file server's cons
On Thu, 6 Aug 2009 22:50:33 -0400
Anthony Sorace 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.
Oh God, n
On Fri, Aug 7, 2009 at 9:05 AM, Ethan Grammatikidis wrote:
> On Thu, 6 Aug 2009 11:33:18 +0100
> "Steve Simon" 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.
>>
>
On Thu, 6 Aug 2009 11:33:18 +0100
"Steve Simon" 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 your friends
>
> 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.
> ...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
On Thu, Aug 6, 2009 at 8:04 PM, Daniel Lyons 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 on one of
> th
On Thursday 06 August 2009 21:19:05 lu...@proxima.alt.za wrote:
> 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 be
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 keyb
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 nobraine
> I honestly can't believe that this is even up for debate!
>
> 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
fo
> 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
> I honestly can't believe that this is even up for debate!
>
> 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
fo
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
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;
> 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.
> 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
don't forget to take away the connectors from the power and reset
buttons, otherwise good security concepts;)
On Thursday 06 August 2009 17:01:30 John Floren wrote:
> On Thu, Aug 6, 2009 at 4:28 PM, Corey wrote:
> > I honestly can't believe that this is even up for debate!
> >
> > It's just bizarre.
>
> Oh, if we're just protecting against people wandering by who are
> obviously there by mistake--since
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!
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 du
On Thu, Aug 6, 2009 at 5:01 PM, John Floren wrote:
>
> Oh, if we're just protecting against people wandering by who are
> obviously there by mistake--since we're discounting anyone coming
> prepared for serious maliciousness--how about just not having a
> terminal connected to your file server? My
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 I
On Thu, Aug 6, 2009 at 4:28 PM, Corey wrote:
> On Thursday 06 August 2009 01:19:35 Robert Raschke wrote:
>> On Thu, Aug 6, 2009 at 8:52 AM, Corey wrote:
>
>> > That wasn't a rhetorical question. Why bother locking your door?
>> >
>> > Any intruder worth his weight in salt can circumvent such a s
On Thursday 06 August 2009 01:19:35 Robert Raschke wrote:
> On Thu, Aug 6, 2009 at 8:52 AM, Corey wrote:
> > 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.
>
> Why lock
On Wed, Aug 5, 2009 at 11:30 PM, John Floren wrote:
> On Wed, Aug 5, 2009 at 11:15 PM, Corey 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 s
> 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 a
> Works like a charm. Knowing the the correct manual page(s) to be looking
> at certainly helps!
>
> 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
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 m
On Thu, Aug 6, 2009 at 8:52 AM, Corey 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 opinions which differ
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 Wed, Aug 5, 2009 at 11:15 PM, Corey 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 cpu/auth se
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 s
> "/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 got directoried.
remove and replace.
> * Could anyone expl
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 wron
49 matches
Mail list logo
