From: Dev [mailto:[email protected]] On Behalf Of Rafal Krypa Sent: Friday, June 20, 2014 5:47 AM To: [email protected] Subject: [Dev] Crosswalk multi-user implementation vs. Smack
The two are not at odds. Or, should I say, the three. Hi, I have investigated current Crosswalk behavior with respect to multi-user and I think that we may have some incompatibilities with platform security design. The security team and the Crosswalk team are working closely to ensure that Crosswalk performs its role in platform security properly. It seems that web applications are now installed per user. Yes, this is a multi-user requirement. Otherwise if Fred installs an application Pebbles will always have access to it. I found application data installed into ~/.config/xwalk-service/applications/$APP_ID and aplication information stored in ~/.application. Using xwalkctl I was able to install the same application for multiple users. The app was assigned the same application and package id for user. Which is correct. It gets the same application ID because it is the same application, and it gets the same package id because it came from the same package. This is something slightly different than I heard before and expected. It shouldn’t be. It is the only rational way to allow two users to maintain their own distinct application environments. And I think it forces us to revisit Smack label assignment for applications. No, this is exactly what it expected and desired. With applications installed locally in user home, it is unfeasible to base Smack label only on package id. This would lead to multiple users having applications with the same label. Yes. This is intentional. We have a requirement for application isolation. Not application instance isolation. Not application instance invocation isolation. This is important. Consider two people in a car (backseat, of course!) each running their own copy of SwordSwinger (in “fight to the death” mode). The application expects to interact with other instances of itself running on the device. That is how it provides a delightful user experience. Those applications could have entirely different set of permissions (e.g. different versions of the same app or id collision for two unrelated applications). If application management is to be done entirely per-user, a different Smack labeling will be required. You are leaving out what differentiates users, which is the UID. The UID is a security attribute of the process, just like the Smack label. One obvious solution would be to build Smack label from package id AND user identifier. Down side of this would be multiplication of Smack labels in the system and proportional growth of policy size. Yes, that is one option we would consider if we didn’t have UIDs. Because processes have a Smack label and a UID we can always differentiate between SwordSwinger run by Fred and SwordSwinger run by Barney. If Fred wants to allow the application to update the internet scoreboard, and Barney doesn’t, that’s easy to do. Cynara understands both Smack labels and UIDs. There is no need to panic. It’s all under control. … I think.
_______________________________________________ Dev mailing list [email protected] https://lists.tizen.org/listinfo/dev
