Re: Seeking advice on automounter-like daemon starting at boot
Hi Gustavo,
On Mon, Oct 18, 2010 at 3:19 AM, gustavo panizzo <gfa> <gfa@zumbi.com.ar> wrote:
>> > d) Create an user "udisks", add a PolicyKit rule to allow it to mount
>> > device files, use that for the init script (not even sure it's
>> > possible)
>> how would it leave the file permissions on the mounted filesystems?
>> Would them be readable/writable by local users?
> i was referring to option D
> if the udisks user has plugdev (or something like that) as primary
> group and the filesystem is mounted with umask 220 it should work (if
> the local user is part of plugdev group)
By default, not even an user in the plugdev group can mount with
udisks --mount. You really need to have an active ConsoleKit session,
it seems (see /usr/share/polkit-1/actions/org.freedesktop.udisks.policy).
It might be possible to set up a policy to override this and make
users in plugdev able to mount non-system devices, but that would be
wrong in so many ways.
As for the umask of the mounted filesystem, that's perhaps not so much
of a problem. udisks --mount has an option --mount-options that can
probably be used to supply options like umask=022. But still, the user
running udisks --mount would need to have plugdev as its login group,
and root obviously doesn't. That alone wouldn't solve the problem of
running udisks-glue as root, either. The mount point is also
determined by udisks, so it's not like I could (or even should) create
it first and assign the right permissions.
I don't even know if there would be a way to accomplish d) at all
without introducing a major security hole. After all, it seems that a
daemon such as udisks-glue, which ultimately relies on ConsoleKit for
authorization (through udisks and then PolicyKit), isn't easily
retrofitted into a structure that isn't session-aware. I'm leaning
towards c) (keeping the configuration file around but not installing
any init script). Would that be acceptable?
Thanks in advance,
Reply to: