> [ discussion of workman from volmgr; it works]
> Yes, but there are 2 drawbacks:
> - you must allow root to display anything on your display by issueing
> - as workman is started as root, it can have some trouble to
> read (and eventually lock and/or write) your database
> (~/.workmandb), except if you enable access to everybody.
> Correct me if i am wrong.
You are wrong. If you are logged in on /dev/console when you started
OpenWin (and how could you not be?), workman_action.so does a setuid
to the current owner of /dev/console before starting workman, so that
your .Xauthority, setup by the openwin startup script, will allow it
to open a window on your display.
Oh, you think I'm dreaming? Vell, here is ze proof! :-)
Here is truss(1) output to show this happening:
# ps -ae | grep vol
177 ? 0:02 vold
# truss -o j -f -p 177
# vi j # trim it down to fit USENET guidelines :-)
# Here it stats /dev/console to see who the owner is
283: stat("/dev/console", 0xEFFFFA28) = 0
# Look up the numeric uid to ensure it's a valid user on this system:
283: open("/etc/nsswitch.conf", O_RDONLY, 0666) = 10
# 20 lines of figuring out that I don't use NIS deleted
283: open("/etc/passwd", O_RDONLY, 0666) = 10
283: fstat(10, 0xEFFFF598) = 0
283: ioctl(10, TCGETA, 0xEFFFF524) Err#25 ENOTTY
283: read(10, " r o o t : x : 0 : 1 : 0".., 8192) = 1073
283: lseek(10, 0xFFFFFDE0, 1) = 529
283: close(10) = 0
# and set its uid and gid to me (100/3)
283: setuid(100) = 0
283: seteuid(100) = 0
283: setgid(3) Err#1 EPERM
283: setegid(3) Err#1 EPERM
# Then some 20 lines later it does an execve("/path/workman", .., which
# starts workman running as me. I do not run with any hosts xhosted,
# and I'm now listening to Beethoven's Ninth.
So, this aspect of volume management is pretty well thought out, and it
works, at least for standard cases.