Privacy (su UID value in desktop entry standard)

[Linas Vepstas]

Hi,

On Fri, Mar 19, 2004 at 12:38:04PM +0100, C. Gatzemeier was heard to remark:
> Am Freitag, 19. M?rz 2004 05:11 schrieb Linas Vepstas:
> > On Thu, Mar 18, 2004 at 08:12:23PM +0100, C. Gatzemeier was heard to remark:
> > > If you have KDE running you can try the following, seems to work pretty
> > > nice. kdesu -u [user] gnucash
> > > (I am sure there are also Gnome etc. variants available)
> >
> > Yes, this was discussed a bit; It works, but falls somewhat into
> > the "put it in a HOWTO" category, since there is some non-trivial
> > sysadmin work to set up the 'protected' user.
> [...]
> 
> I am scratching my head here a little, and wondering what kind of 
> functionality you are picturing. I think the desktop-su-HOWTO style taste 
> shoud go away with proper GUI integration.

You can stop scratching your head, I think you've got it exactly right.

> Let me draw this little scenario:
> 
> A future Deskop distribution is set up to boot right into the graphical 
> desktop logged in as a local guest (or think family) user.
> Things can be done just as usual. But if one wants to do somthing private he 
> obviously will unavoidably need a private account (easily set up). He 
> notices/can see he has two alternatives. 
> One he can click on the session aware pager to switch to a parallel running 
> session, log in, and do anything in his own homedirectory.
> 
> Alternatively he just fires up the desired app.
> 
> Mail, bookkeeping programs etc. can be installed "asking for 
> authentication" (install script will have set up a desktop entry with 
> "prompt-for-run-as-username")
> Other apps can also be right-clicked and be "run as..." And of course the 
> property to "allways run as ..." is there so just the password without extra 
> username is asked.
> 
> Windows running under different UID than the session are titled including 
> username like "Lokal Folder - KMail [Christian]" and could have a "window 
> lock" timeout" analogous to xlock.

Yes, all of the above exactly as described.

> >  Do I need to 'kdesu -u bookeeper konqueror'
> > to do graphical file management? 
> >
> > Remember, my goal was to allow my proverbial computer-novice-mom
> > to keep her accounting files under lock and key, while otherwise
> > keeping the desktop open to all.
> 
> I'd picture a system aware filebrowser to just ask our computer-novice-moms 
> for appropriate user/group passwords when she is about to open her locked 
> directory or file instead of "accsess denied"
> 
> Could it be that easy?

Yes. It SHOULD be that easy.

>From the "User Experience" persepective, I think you've described it exactly.

>From the 'how to actually implement this' I suspect that there are
a number of devilish details, especially in the interaction between
the finder and other apps.  e.g. where on the desktop do locked files
appear? Does the 'guest' desktop always show the files of all other users?
Do we need to reinvent hidden files?  Do permissions work at file
level or directory level?  What is the mapping between the "user
Experience" and UNIX ACL's?  (reiserfs, ext2fs both now have fancy
ACL's in the 2.6 kernel, some of the other fs's do not).
How can I copy from user A to user B? (e.g. from user 'home-accounting' 
to user 'linas-mail'), how can I do that copy so that it doesn't expose 
security holes for future crackers/worms/viruses ? 

I don't have answers to these; these are just some of the issues I could
think of quickly.  I was sort of hoping that some of this had already
been discussed a bit on the desktop mailing lists.  e.g. Havoc
Pennington, I'm not sure why he is burning brain cells thinking 
about C# instead of the above ... 

--linas

-- 
pub  1024D/01045933 2001-02-01 Linas Vepstas (Labas!) <linas at linas.org>
PGP Key fingerprint = 8305 2521 6000 0B5E 8984  3F54 64A9 9A82 0104 5933