On 2014-01-06, 10:29 -0800, Kok, Auke-jan H wrote: > > [ BTW, a small discussion, about the "user" part, do you prefer uid or > > a name? i.e.: [email protected] vs > > [email protected] > > ever since systemd-185 or so it has standardized on uid's, so we > should use them everywhere as much as we can.
OK. > > pam_systemd.so can handle user name (e.g.: app) quite well, plus > > benefits we don't need code to translate that 5000 into "app" in > > launcher.c ] > > struct passwd pw = getpwuid(uid); > -> pw.pw_nam > > easy enough, and we don't have problems with escaping, utf-8 user > names, etc etc.... Sure. I just thought we could possibly leave this kind of authentication to PAM. It's a nitpicking anyway. Thanks. > > I think one major problem left in this user session setup is that, > > those user session services be run each time a new user session opens > > (e.g. somewhere another user "root" login). > > step #2 isn't done yet - we need a user service (e.g. [email protected]) > that can start the proper seat for a user and then start either X with > DISPLAY=whatever or start wayland if the seat was designated by the > user for a wayland session.... this code isn't written yet. > > > We can fiddle with PAM configurations (/etc/pam.d) to work around > > this. > > > > Or, we need to clean up all those user session units. I mean, do they > > really belongs to *user session*? > > they belong to the user, we don't need them on every installation.... > but they are not system stuff. OK, I understand you now, you're assuming every user logged in needs his own whole UI stack. Hmm, sounds reasonable. Still one issue left: with the currently system setup, when a user does not have seat login (e.g.: ssh or sdb/su), [email protected] will still try to launch the whole UI stack... This can be fixed maybe by changing the PAM settings: removing the pam_systemd.so from login and su PAM config files. What do you think? > > bash-4.2# cd /lib/systemd/user > > bash-4.2# ls > > bluetooth-frwk-service.service quickpanel.service > > bluetooth.target scim.service > > boot-animation.service shutdown.target > > calendar.service smartcard.target > > contacts-service.service sockets.target > > contacts-service.socket sockets.target.wants > > core-efl.target sound.target > > core-efl.target.wants starter.path > > data-provider-master.service starter.service > > data-provider-master.socket systemd-exit.service > > dbus.service timers.target > > dbus.socket tizen-generate-env.service > > default.target tizen-middleware.target > > download-provider.service tizen-middleware.target.wants > > e17_early.service tizen-mobile-session.target > > e17.service tizen-mobile-session.target.wants > > email.service xmodmap.service > > exit.target xorg_done.service > > indicator.service xorg.service > > paths.target xorg.target > > printer.target xorg.target.wants > > bash-4.2# > > > > Most of these are middle ware services, can we move those into system > > session, and just run them with "User=app"? > > Nope, nope, no hard coded end users. That's completely wrong. We're > trying to get rid of all the hard coded usernames and uid's, we should > be removing them, not add more occurrences. "app" is not a dynamic added username/uid, it's built-in :) Do you mean we have the possibility of adding all these users dynamically, after system is set up? But yeah I agree moving these UI services back to system and specifying usernames does not scale to multi-user scenario... Thanks, Kangkai _______________________________________________ Dev mailing list [email protected] https://lists.tizen.org/listinfo/dev
