> tickle% cat /mnt/factotum/ctl
> key proto=rsa service=sshserve owner=* size=1024 ek=19
> n=E6468F8D8C04826CD398EFCBDE2593187A8A6C5CE76351ABDF52A15A4682F58582992B14005A6CE18ADDF8029AC94CBD3E32D6DCECEB6D441897D6D50199F9531D7666BAD87BD59148F3C6EF36D2BA8B5BB795385FD7E12810E25BCB0499B01B169011C839BD0
> ; ls -l /mnt/factotum/ctl
> --rw-r--r-- M 53 eve eve 0 Nov 27 11:22 /mnt/factotum/ctl
> ; cat /mnt/factotum/ctl
But once I add an RSA key with an owner=* attribute, I get:
tickle% cat /mnt/factotum/ctl
key proto=rsa service=sshserve owner=* size=1024 ek=19
n=E6468F8D8C04826CD
> >> so i don't think that '*' is required. however i think that
> >> running from /rc/bin/service.auth is.
> >
> > You can do one or the other.
>
> The latter should be deprecated, the former uses the Plan 9 security
> model as intended. At least, that's my _opinion_.
they're not equivalent.
On Fri Nov 27 10:22:32 EST 2009, 9f...@hamnavoe.com wrote:
> > none doesn't have access to eve's factotum, so you have to
> > run sshserve from a trusted listen anyway.
>
> Maybe your configuration is non-standard. Normally /lib/namespace
> mounts /srv/factotum on /mnt, and /mnt/factotum/ctl has
> /mnt/factotum/ctl has rw-r--r--
> permission so anyone can read it.
In fact /mnt/factotum/rpc has rw-rw-rw- permissions. I think that's
telling (to state the obvious).
++L
>> so i don't think that '*' is required. however i think that
>> running from /rc/bin/service.auth is.
>
> You can do one or the other.
The latter should be deprecated, the former uses the Plan 9 security
model as intended. At least, that's my _opinion_.
++L
> none doesn't have access to eve's factotum, so you have to
> run sshserve from a trusted listen anyway.
Maybe your configuration is non-standard. Normally /lib/namespace
mounts /srv/factotum on /mnt, and /mnt/factotum/ctl has rw-r--r--
permission so anyone can read it.
> so i don't think that
> this is documented in factotum(4) at the top of the section
> "Key Tuples". the key relationshop is that
> hex := f(password)
> where f is passtokey (/sys/src/libauthsrv/passtokey.c). so
> hex and password have equivalent functionality.
Appreciated, thank you.
++L
On Fri Nov 27 05:34:24 EST 2009, lu...@proxima.alt.za wrote:
> And another equally silly question, maybe there's someone else out
> there that can learn from my mistakes and/or ignorance: the factotum
> on the CPU server does not contain all the keys "eve" is entitled to,
> in fact, it only contain
> none doesn't have access to eve's factotum, so you have to
Not true, the permissions are quite relaxed (at least, this agrees
with my experience):
tickle% ls -ld /mnt/factotum
d-r-xr-xr-x M 642 proxima proxima 0 Nov 27 17:14 /mnt/factotum
tickle% ls -l /mnt/factotum
> Reading /mnt/factotum/ctl only gives you the keys you are allowed to use.
>
> factotum(4) says:
>
> The factotum owner can use any key stored by factotum. Any
> key may have one or more owner attributes listing the users
> who can use the key as though they were t
>>If it is, there's a depth of cleverness in the new Plan 9
>>security model that I had missed until now, namely the elimination of
>>the intermediate "superuser" step required by the Unix paradigm.
>
> indeed that's the point.
Too clever for my ageing brain :-) Of course, I knew the facility
exi
>If it is, there's a depth of cleverness in the new Plan 9
>security model that I had missed until now, namely the elimination of
>the intermediate "superuser" step required by the Unix paradigm.
indeed that's the point.
> Therefore the example in ssh(1) for generating a key should say:
>
> auth/rsagen -t 'service=sshserve owner=*' >/mnt/factotum/ctl
This is the stuff that my literal mind copes poorly with :-) I would
never have picked this up. If you don't mind, there's more
clarification I need on this i
> The failure mode was reported as a missing "service=sshserve" key in
> factotum, whereas it seems to have been a file access (permissions?)
> problem (none can't get where eve can). That none can Bopen()
> /mnt/factotum/ctl but can't read its contents is also a bit strange.
Reading /mnt/factotu
15 matches
Mail list logo