> -----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
