Re: [9fans] acme multi-line tags (or maybe, efficient message stores)
On Monday 10 of October 2011 05:21:22 erik quanstrom wrote: didn't have the time to make that change. That said, I find acme (and Edit in particular) damned near unusable without multi-line tags now. do you have a particular usage senerio where this is most apparent? when editing multi-file project, my tags often holds bookmarks of 2...4 locations in current file, usually as symbol matchign regex (:/SYMBOL_NAME), plus scratchpad for 1...2 Edit commands. using p9p acme. -- dexen deVries [[[↓][→]]] http://xkcd.com/732/
Re: [9fans] tcl, 9p
On 10/09/2011 08:04 AM, Russ Cox wrote: On Sat, Oct 8, 2011 at 8:02 PM, L Nleonardne...@gmail.com wrote: Anyone know the state of the art of writing 9p clients/servers in tcl? I believe the state of the art is not to use tcl. :-) I'm having fun writing 9p clients in Go. IMHO, That Go or Go-language thingy seems to be an overkill to me for that matter; that's just an opinion and opinions may differ. The best portable and efficient intermediate level language is C and I hope it will remain a 'lingua franca' for computer programmers for years to come ;) -- Balwinder S bdheeman Dheeman (http://werc.homelinux.net/contact/)
Re: [9fans] copying fossil filesystem to a bigger disk
that's a good question. if you just want to copy everything, i use the shell
idiom
disk/mkfs {echo +}
I ran this in /usr/bootes/ as bootes:
su# disk/mkfs -a -s / {echo +} arch
processing /fd/7
mkfs: /fd/7:1: can't open //dev/consctl: '//dev/consctl' permission denied
mkfs: /fd/7:1: can't open //dev/kprint: '//dev/kprint' device or
object already in use
I guess it wasn't the brightest idea, because the arch file grew much
bigger than all my files put together on the old drive.
Should I mount the new drive to /n/kfs and not use the -a option? I
was a little confused about these references to kfs while my
filesystem is fossil.
Re: [9fans] copying fossil filesystem to a bigger disk
No error, no crash. Just some files/dirs are not copied to new destination. du -s gives different number on linux vs. ext2srv/plan9 native./ Also, du -a | wc -l differ. I was not able to identify any system in which files/ dirs do not appear on ext2srv. First, i thought that dirs with 120 files, or so, are affected annd/or there's some size limit (like 2GB), but this was not the case. I can investigate it deeper, if you are interested. Should I send you a diff of du -a from linux vs. ext2srv? Thank you for your care, regards, Peter. On Fri, Oct 7, 2011 at 3:03 PM, Steve Simon st...@quintile.net wrote: Out of interest - what is the problem with ext2srv with too many files/subdirs? what error does it give, does it crash? -Steve
[9fans] p9any auth in u9fs: uid value in ticked is ignored
There is a security problem with p9auth in u9fs: it uses uname from
Tauth/Tattach as user's identity - ignoring the user id which has been
authenticated to the auth server. As uname is always set to up-user
in devmnt, this means that:
a) a user cann't have a different name on the u9fs machine; and, more
serious,
b) a user can easily masquerade as another user to u9fs by simply
booting his terminal under that user while using own credentials for
optaining the ticket.
A proposed fix has been submitted as /n/sources/patch/u9fs-p9sk1:
/n/dump/2011/1010/sys/src/cmd/unix/u9fs/authp9any.c:369,375 -
/sys/src/cmd/unix/u9fs/authp9any.c:369,378
fprint(2, p9anyattach: afid %d state %d\n, rx-afid,
sp-state);
if (sp-state == Established strcmp(rx-uname, sp-uname) == 0
strcmp(rx-aname, sp-aname) == 0)
+ {
+ rx-uname = sp-t.suid;
return nil;
+ }
return authentication failed;
}
Whether to use t.suid or t.cuid as the target uid remains an open
question: authsrv(6) says t.suid represents target uid; the real use,
howerver, is not that clear: cwfs for 9p2k uses t.suid; while fossil,
exportfs, cpu -R and cwfs for old9p check against t.cuid. Comments in
/sys/include/authsrv.h:58,76 appear somewhat opaque until authsrv(6)
and p9sk1 client/server code in factotum are carefully studied.
- Yaroslav
─
Related matter:
/sys/src/9/port/devmnt.c:281
/sys/src/9/port/devmnt.c:347
/sys/src/cmd/auth/factotum/p9sk1.c:170,171
/sys/src/cmd/auth/factotum/rpc.c:341
/sys/src/libauth/auth_chuid.c:37
/sys/src/cmd/unix/u9fs/authp9any.c:370
/sys/src/cmd/unix/u9fs/u9fs.c:417,420
/sys/src/cmd/cpu.c:665
/sys/src/cmd/fossil/9auth.c:30,38
/sys/src/cmd/fossil/9auth.c:132,151
/sys/src/cmd/fossil/9auth.c:155
/sys/src/cmd/fossil/9p.c:999,1007
/sys/src/cmd/cwfs/9p1.c:134,138
/sys/src/cmd/cwfs/9p2.c:252,262
/sys/src/cmd/cwfs/auth.c:313
/sys/src/cmd/cwfs/auth.c:291
/sys/src/cmd/exportfs/exportfs.c:189,192
Re: [9fans] p9any auth in u9fs: uid value in ticked is ignored
It's true that the server must take account of the result of authentication, but although that might not mean identity, the results of authentication should be consistent with the name presented as uname in Tauth/Tattach. In the context of p9auth I think that means that the cuid of AuthInfo should match. That doesn't preclude the server from having a more subtle acquisition of authority, for instance by having an auth file that's kept open, allowing incremental authentication using another protocol. On 10 October 2011 13:07, Yaroslav yari...@gmail.com wrote: There is a security problem with p9auth in u9fs: it uses uname from Tauth/Tattach as user's identity - ignoring the user id which has been authenticated to the auth server. As uname is always set to up-user in devmnt, this means that:
Re: [9fans] copying fossil filesystem to a bigger disk
su# disk/mkfs -a -s / {echo +} arch
processing /fd/7
mkfs: /fd/7:1: can't open //dev/consctl: '//dev/consctl' permission denied
mkfs: /fd/7:1: can't open //dev/kprint: '//dev/kprint' device or
object already in use
I guess it wasn't the brightest idea, because the arch file grew much
bigger than all my files put together on the old drive.
Should I mount the new drive to /n/kfs and not use the -a option? I
was a little confused about these references to kfs while my
filesystem is fossil.
you're not the first person to make this mistake, so i should
have remembered this problem. sorry.
you need to mount both new and old afresh in /n/ and copy
using your destination as /n/new and source as /n/old. using
/ as your source doesn't work because you have many things other
than the file server intended mounted. for example, your first
error messages are because #c is mounted on /dev.
- erik
Re: [9fans] tcl, 9p
C is a low level language, not intermediate. In the second decade of the 21st century is it too much to ask for garbage collection and type safety? Hmm. I'm probably just feeding a troll. Paul On Mon, Oct 10, 2011 at 2:05 AM, Balwinder S Dheeman bsd.sans...@anu.homelinux.net wrote: On 10/09/2011 08:04 AM, Russ Cox wrote: On Sat, Oct 8, 2011 at 8:02 PM, L Nleonardne...@gmail.com wrote: Anyone know the state of the art of writing 9p clients/servers in tcl? I believe the state of the art is not to use tcl. :-) I'm having fun writing 9p clients in Go. IMHO, That Go or Go-language thingy seems to be an overkill to me for that matter; that's just an opinion and opinions may differ. The best portable and efficient intermediate level language is C and I hope it will remain a 'lingua franca' for computer programmers for years to come ;) -- Balwinder S bdheeman Dheeman (http://werc.homelinux.net/**contact/ http://werc.homelinux.net/contact/ ) -- I'm migrating my email. plalo...@telus.net will soon be disconnected. Please use paul.a.lalo...@gmail.com from now on.
Re: [9fans] tcl, 9p
It's not necessary that you're feeding a troll, in my opinion. I actually agree with the idea that C is enough. I don't understand why you need garbage collection ... why do you need to have garbage in the first place? Just because time goes by does not mean everything should keep on changing you know. People have to understand that certain technologies can just stay as they are, if they work well. Simon On Mon, Oct 10, 2011 at 3:33 PM, Paul Lalonde paul.a.lalo...@gmail.com wrote: C is a low level language, not intermediate. In the second decade of the 21st century is it too much to ask for garbage collection and type safety? Hmm. I'm probably just feeding a troll. Paul On Mon, Oct 10, 2011 at 2:05 AM, Balwinder S Dheeman bsd.sans...@anu.homelinux.net wrote: On 10/09/2011 08:04 AM, Russ Cox wrote: On Sat, Oct 8, 2011 at 8:02 PM, L Nleonardne...@gmail.com wrote: Anyone know the state of the art of writing 9p clients/servers in tcl? I believe the state of the art is not to use tcl. :-) I'm having fun writing 9p clients in Go. IMHO, That Go or Go-language thingy seems to be an overkill to me for that matter; that's just an opinion and opinions may differ. The best portable and efficient intermediate level language is C and I hope it will remain a 'lingua franca' for computer programmers for years to come ;) -- Balwinder S bdheeman Dheeman (http://werc.homelinux.net/contact/) -- I'm migrating my email. plalo...@telus.net will soon be disconnected. Please use paul.a.lalo...@gmail.com from now on.
Re: [9fans] p9any auth in u9fs: uid value in ticked is ignored
devmnt always uses up-user for Tauth/Tattach no matter what an auth protocol would yield (/sys/src/9/port/devmnt.c:281). Stock 9P servers tolerate this and check Tattach.uname to match Tauth.uname but use t.cuid or t.suid as the true user identity (unless no auth required). Anyway, simply trusting Tattach.uname is too naïve - at least for p9any. It's true that the server must take account of the result of authentication, but although that might not mean identity, the results of authentication should be consistent with the name presented as uname in Tauth/Tattach. In the context of p9auth I think that means that the cuid of AuthInfo should match.
Re: [9fans] p9any auth in u9fs: uid value in ticked is ignored
Indeed the whole point of Tauth is that the uname in Tattach isn't intended to be trusted on its own, unless supported by an afid that attests to a previous authentication of the uname. (An exception is that many servers only run as the invoking user and don't insist on authentication.) That's the documented protocol. It seems that the servers you mention substitute t.cuid at the attach, but that makes uname relatively pointless: it might just as well not be provided in Tauth since it's effectively ignored. It would be needed in Tattach in case there is no Tauth, but is also effectively ignored in Tattach if there were a Tauth. (In that case, who cares if the two strings are the same if they are irrelevant? What's the point of the server checking?) That isn't the documented protocol. I'm ignoring the devmnt aspect because that's outside the protocol as such. I'm interested in what servers ought to be doing (or perhaps whether the protocol should be change).
Re: [9fans] tcl, 9p
I wrote my first significant software project in 1971 in IBM 1620 assembly language. When I got done, I felt I was equipped to develop anything. In my subsequent job in a COBOL shop I became the house curmudgeon, sure that the language just got in the way. But looking back, there is no way we could have accomplished what we did in assembler. It's not that we're not all Von Neumanns, it's that if you want to accomplish bigger and bigger things you have to rely upon inefficient, inexpert automation to assume the burden of detail. Same way with people: you have to delegate, even though you know you can do it 5x better and faster than the people you delegate to. And look at it this way: delegation helps the economy by employing people and selling processors and memory :-) Wes Kussmaul On Mon, 2011-10-10 at 15:51 +0200, simon softnet wrote: It's not necessary that you're feeding a troll, in my opinion. I actually agree with the idea that C is enough. I don't understand why you need garbage collection ... why do you need to have garbage in the first place? Just because time goes by does not mean everything should keep on changing you know. People have to understand that certain technologies can just stay as they are, if they work well. Simon On Mon, Oct 10, 2011 at 3:33 PM, Paul Lalonde paul.a.lalo...@gmail.com wrote: C is a low level language, not intermediate. In the second decade of the 21st century is it too much to ask for garbage collection and type safety? Hmm. I'm probably just feeding a troll. Paul On Mon, Oct 10, 2011 at 2:05 AM, Balwinder S Dheeman bsd.sans...@anu.homelinux.net wrote: On 10/09/2011 08:04 AM, Russ Cox wrote: On Sat, Oct 8, 2011 at 8:02 PM, L Nleonardne...@gmail.com wrote: Anyone know the state of the art of writing 9p clients/servers in tcl? I believe the state of the art is not to use tcl. :-) I'm having fun writing 9p clients in Go. IMHO, That Go or Go-language thingy seems to be an overkill to me for that matter; that's just an opinion and opinions may differ. The best portable and efficient intermediate level language is C and I hope it will remain a 'lingua franca' for computer programmers for years to come ;) -- Balwinder S bdheeman Dheeman (http://werc.homelinux.net/contact/) -- I'm migrating my email. plalo...@telus.net will soon be disconnected. Please use paul.a.lalo...@gmail.com from now on.
Re: [9fans] p9any auth in u9fs: uid value in ticked is ignored
Uname in Tauth/Tattach indeed seem to be irrelevant for p9any but as it is external to 9P this may be a provision for other possible auth schemes where the uname may be the only place to provide an indentity being authenticated...
Re: [9fans] tcl, 9p
Speaking as someone who is too old and senile and stupid even to become a High Court Judge, I find the lack of improvements to Tcl to be a major attraction. I don’t need to program in it that often – I maintain one moderately-sized script which hardly ever changes - but when I need to re-visit it, I find that I can pick it up again easily, unlike whatever moving-target language the cool kids are using this week. It also doesn’t hurt that Ousterhout’s book is a model of clarity.
Re: [9fans] tcl, 9p
On Mon Oct 10 09:52:36 EDT 2011, ph.soft...@gmail.com wrote: It's not necessary that you're feeding a troll, in my opinion. I actually agree with the idea that C is enough. I don't understand why you need garbage collection ... why do you need to have garbage in the first place? Just because time goes by does not mean everything should keep on changing you know. People have to understand that certain technologies can just stay as they are, if they work well. need is such a funny word. we don't need keyboards, we can just use toggles. there have been a few other trivial improvments in the day-to-day lives of programmers like bitmap displays, which real computer scientists can ignore. so as time goes on, it's easy for programmers to get a whiggish view of the world. but you're equally correct, that the mere passage of time between x and y is not an argument that either is better. so we're left only to argue this one on the merits of garbage collection. :-) now that i think of it, garbage collection was invented more than a decade before c. so the preceeding two paragraphs have been argued in the moot court. in any event, i think one can consider manual memory management to often be akin to manually managing registerization. there is a good chance that in most cases that an automatic and systematic process can do a better job than an ad hoc one. yet, i program in c most of the time. i don't know of many operating systems written in a automaticly gc'd language. - erik
Re: [9fans] acme multi-line tags (or maybe, efficient message stores)
On Mon Oct 10 00:08:51 EDT 2011, paul.a.lalo...@gmail.com wrote: I often keep an Edit I'm refining in a separate tag line for easy selection. But the real use was in keeping commands that need chorded parameters, so my debugger sessions, for example, keep a line of list print break etc, so I can chord in the parameter easily. That way I don't have to construct the breakpoint instruction in a scratch window, and I can keep enough of them around to be useful - one tag line isn't big enough. i'd rather have a window like win that would operate on the same principle as the sam edit window. unless i've misread the man page, i don't think this is possible with the current command interface*. you'd have to insert the text into the tag and then execute it. it'd be the opposite of screen scraping. :-) - erik *i want to send Edit X ,s:frobnatz:blatz:g. or Edit b somefile, how do i do that?
Re: [9fans] p9any auth in u9fs: uid value in ticked is ignored
You could just define it in the first write to the auth file. In any
case, there wouldn't
be any need for the names in Tauth and Tattach to match, because the
server would
always use the result of the authentication.
I imagine the intention was that in Tauth, uname defined the user to
authenticate within
the space defined by the given aname (if relevant), and only that
uname (in that aname context)
would be authenticated; consequently it was reasonable to use the
resulting afid to authenticate
one or more matching Tattach requests. Thus the (uname, aname) on
Tauth should really be
constraining the initial state for authentication on the auth file
(ie, on success, it's taken to have
authenticated that uname). For instance, in the p9any case in
role=server, it should also be given user=uname,
and with p9sk1, only uname would be acceptable as {uid sub C}. Then
all the IDs involved would match.
(That doesn't preclude some sort of user name mapping, as is already
done for instance by fossil,
or a map of the name to an internal user ID as done by kfs.)
Note that on a shared server, with several unames actively accessing a
shared file server connection,
the users are trusting the server not to cheat with fids (ie, allow
one user to attach a fid,
however that's done, and then make that fid usable by another user by
accident, or to a miscreant by design).
On 10 October 2011 21:47, Yaroslav yari...@gmail.com wrote:
Uname in Tauth/Tattach indeed seem to be irrelevant for p9any but as
it is external to 9P this may be a provision for other possible auth
schemes where the uname may be the only place to provide an indentity
being authenticated...
