Hi all, I created the Jira task https://bugs.tizen.org/jira/browse/TC-2154 to track that issue.
Also, I threw some notes on the subject in the wiki: https://wiki.tizen.org/wiki/User:Jobol/security_manager_improvements_proposal Best regards José Bollo Le jeudi 20 novembre 2014 à 17:26 +0000, Schaufler, Casey a écrit : > > -----Original Message----- > > From: Dev [mailto:[email protected]] On Behalf Of Rafal Krypa > > Sent: Thursday, November 20, 2014 8:30 AM > > To: [email protected] > > Subject: Re: [Dev] transferring files from and to a service > > > > On 2014-11-20 10:12, Tomasz Swierczek wrote: > > > Okay, so if this is the usecase, then we need to have, like I mentioned, > > > the > > > mv_chmod_chown() API in security-server PLUS some way of authorizing > > this > > > action (ie. guard it with http://tizen.org/privilege/system like it was > > > proposed or some other, more precise privilege, allowed only for > > > system-level things). > > > > > > > > > @Rafal, Casey, others - what is your opinion? > > > > > > We could get a simpler interface if the file would be created already in the > > final destination, at user's home directory. > > I'mthinking about a security-manager API that would implement creation of > > an empty file in the user's home directory and pass the file descriptor to > > the > > caller. The caller (e.g. obexd) would then write to that file descriptor to > > fill it > > with data. Things that security-manager should do in such case: > > - take target user name, file name and type as argument > > - verify privilege, can also trigger popup to get user consent > > - check if the file already exists, guard against overwriting it (either by > > failing > > orappending some string to the file name) > > - create the empty file, set ownership and Smack label > > - send the file descriptor back > > In another thread someone explicitly wanted to create the file > in the service's private place and only pass it to the user when > the file was complete. Something to do with an App getting unhappy > if it tried to read a partial database. The interface you suggest here > might be good, but it doesn't provide the desired behavior. > > Don't even think of trying to provide one interface that sets all > of the attributes. It will be broken the instant some service decides > it needs to use an interface we haven't thought of. It will be safe so > long as the "secman_rename()" gets done last. > > secman_create() > This is special. Create a file that the other > security manager function can act upon. > secman_own() > If the service needs to use an existing file, > call this. If someone else called secman_create() > or secman_own(), this should fail. > > The security manager will remember who "owns" a > file (based on the UID and Smack label of the service) > and only allow that service to make changes. > > secman_chmod() > secman_chacl() > secman_chsmack() > secman_chown() > > These should all be self explanatory. Add more > as the mood suits. > > secman_rename() > > This is move, but use the system call name to > emphasize that you can't cross filesystem boundries. > > secman_close() > > Declare that you're done with this file. > > Oh, and just to be a pain, all paths must be absolute. > > > > Would that satisfy your needs? Or ismore flexibility required for managing > > the downloaded files? > > _______________________________________________ > > Dev mailing list > > [email protected] > > https://lists.tizen.org/listinfo/dev > _______________________________________________ > Dev mailing list > [email protected] > https://lists.tizen.org/listinfo/dev _______________________________________________ Dev mailing list [email protected] https://lists.tizen.org/listinfo/dev
