On Tue, Sep 11, 2012 at 11:51:30PM +0100, Neil Bothwick wrote

> It's the idea of leaving a root console open for all to access that is
> the issue, not the commands you run in it.

Fully agree that's a bad idea. My system uses sudoers. I.e. in
/etc/sudoers.d/001 I have the lines...

user2 d531 = (root) NOPASSWD: /usr/local/bin/ux *
waltdnes d531 = (root) NOPASSWD: /usr/local/bin/ux *

...where /usr/local/bin/ux consists of...

#!/bin/busybox ash
pumount ${1}

...and in my home directory I have ~/bin/um which consists of...

#! /bin/busybox ash
sudo /usr/local/bin/ux ${1}

...So I can, as a regular user, execute at the commandline...

um sdb1

...and /media/sdb1 is unmounted. No need to log on as root or have a
root shell.

--
Walter Dnes <waltdnes@waltdnes.org>
I don't run "desktop environments"; I run useful applications

On Tue, 11 Sep 2012 22:47:21 -0400, Walter Dnes wrote:

> Fully agree that's a bad idea. My system uses sudoers. I.e. in
> /etc/sudoers.d/001 I have the lines...
>
> user2 d531 = (root) NOPASSWD: /usr/local/bin/ux *
> waltdnes d531 = (root) NOPASSWD: /usr/local/bin/ux *
>
> ...where /usr/local/bin/ux consists of...
>
> #!/bin/busybox ash
> pumount ${1}
>
> ...and in my home directory I have ~/bin/um which consists of...
>
> #! /bin/busybox ash
> sudo /usr/local/bin/ux ${1}
>
> ...So I can, as a regular user, execute at the commandline...
>
> um sdb1
>
> ...and /media/sdb1 is unmounted. No need to log on as root or have a
> root shell.

I don't understand, why are you using sudo to run pmount when its core
purpose is to be run by normal users?

% whatis pmount
pmount (1) - mount arbitrary hotpluggable devices as normal user


--
Neil Bothwick

Life's a cache, and then you flush...

120911 Neil Bothwick was worried at the idea
of leaving a root console open for all to access:

My machine is not accessible to anyone else, so it's not a problem here.
Yes, it's not a good idea if you're in a data centre or open-plan office.

--
========================,,======================== ====================
SUPPORT ___________//___, Philip Webb
ELECTRIC /] [] [] [] [] []| Cities Centre, University of Toronto
TRANSIT `-O----------O---' purslowatchassdotutorontodotca

On Wed, Sep 12, 2012 at 09:03:50AM +0100, Neil Bothwick wrote

> I don't understand, why are you using sudo to run pmount when its core
> purpose is to be run by normal users?
>
> % whatis pmount
> pmount (1) - mount arbitrary hotpluggable devices as normal user

A normal user can pumount *WHAT THAT SAME USER* has pmounted. Now try
for a general solution. If you're the only user on the system, it's
probably safe to keep an open xterm logged in to root. The problem is
that inserting a USB device sets off a kernel event, that is passed to
mdev, which looks for a script name in /etc/mdev.conf. If a script is
found that matches the device spec (i.e. sd[a-z].*), e.g. my automount
script, then the script is launched *AS ROOT*. Given that root has
mounted the device, only root can unmount it. E.g. when root pmounts a
device and normal user tries to pumount it, I get...

waltdnes@d531 ~ $ pumount sdb1
Error: device /dev/sdb1 was not mounted by you

Note also that the automount script has to first create a directory in
/media, before mounting it. Since /media is drwxr-xr-x the directory
has to be created by root, or else I have to open up /media to writing
and directory creation by all users. The most secure approach is to
have the system do things as root without user intervention, as much as
possible.

--
Walter Dnes <waltdnes@waltdnes.org>
I don't run "desktop environments"; I run useful applications

On Thu, 13 Sep 2012 02:50:27 -0400, Walter Dnes wrote:

> > I don't understand, why are you using sudo to run pmount when its core
> > purpose is to be run by normal users?
> >
> > % whatis pmount
> > pmount (1) - mount arbitrary hotpluggable devices as normal user
>
> A normal user can pumount *WHAT THAT SAME USER* has pmounted.

Ah, sorry. I didn't read your post carefully enough and saw pmount when
you were using pumount. Using sudo for that makes sense.

> Now try
> for a general solution. If you're the only user on the system, it's
> probably safe to keep an open xterm logged in to root. The problem is
> that inserting a USB device sets off a kernel event, that is passed to
> mdev, which looks for a script name in /etc/mdev.conf. If a script is
> found that matches the device spec (i.e. sd[a-z].*), e.g. my automount
> script, then the script is launched *AS ROOT*. Given that root has
> mounted the device, only root can unmount it.

It's exactly the same problem when udev is used to mount a device, which
is why I prefer to have a process running as the logged in user doing
that, whether it be something incorporated into the DE or a separate
daemon started from ~/.xinitrc.

It gets messy if you are running a multi-seat system, but if only one
user is running X at a time, it is the cleanest way. Of course, as you
are having mdev run a script, you could get that script to check which
user is logged into X and use su to mount it for them, avoiding the
umount issues.


--
Neil Bothwick

Like an atheist in a grave: all dressed up and no place to go.

On Thu, Sep 13, 2012 at 1:50 AM, Walter Dnes <waltdnes@waltdnes.org> wrote:
> On Wed, Sep 12, 2012 at 09:03:50AM +0100, Neil Bothwick wrote
>
>> I don't understand, why are you using sudo to run pmount when its core
>> purpose is to be run by normal users?
>>
>> % whatis pmount
>> pmount (1) - mount arbitrary hotpluggable devices as normal user
>
> A normal user can pumount *WHAT THAT SAME USER* has pmounted. Now try
> for a general solution.

The general solution is using something like udisks+polkit. That is a
true general solution; otherwise you end up like the author of
calibre, with a security mess on his hands:

https://bugs.launchpad.net/calibre/+bug/885027

If you dismiss the security implications of sudoing pmount, because
you care only about *your* use cases, on *your* machine, by definition
that is not a "general solution".

Of course, udisks/polkit/etc. goes hand in hand with udev, so you are
probably not interested in using them. That is completely fine.

Just don't call it a "general solution".

Regards.
--
Canek Peláez Valdés
Posgrado en Ciencia e Ingeniería de la Computación
Universidad Nacional Autónoma de México

On Thu, 13 Sep 2012 09:19:19 -0500, Canek Peláez Valdés wrote:

> > A normal user can pumount *WHAT THAT SAME USER* has pmounted. Now
> > try for a general solution.
>
> The general solution is using something like udisks+polkit. That is a
> true general solution; otherwise you end up like the author of
> calibre, with a security mess on his hands:
>
> https://bugs.launchpad.net/calibre/+bug/885027
>
> If you dismiss the security implications of sudoing pmount, because
> you care only about *your* use cases, on *your* machine, by definition
> that is not a "general solution".

You should never need to sudo pmount, it is supposed to run as a normal
user. Walter is using sudo to run pumount, which is nothing like the
situation described in that bug. Even pmount avoids the situations
described in that bug because it is only capable of operating in /media.


--
Neil Bothwick

A man wrapped up in himself makes a very small package.

On Thu, Sep 13, 2012 at 9:42 AM, Neil Bothwick <neil@digimed.co.uk> wrote:
> On Thu, 13 Sep 2012 09:19:19 -0500, Canek Peláez Valdés wrote:
>
>> > A normal user can pumount *WHAT THAT SAME USER* has pmounted. Now
>> > try for a general solution.
>>
>> The general solution is using something like udisks+polkit. That is a
>> true general solution; otherwise you end up like the author of
>> calibre, with a security mess on his hands:
>>
>> https://bugs.launchpad.net/calibre/+bug/885027
>>
>> If you dismiss the security implications of sudoing pmount, because
>> you care only about *your* use cases, on *your* machine, by definition
>> that is not a "general solution".
>
> You should never need to sudo pmount, it is supposed to run as a normal
> user. Walter is using sudo to run pumount, which is nothing like the
> situation described in that bug. Even pmount avoids the situations
> described in that bug because it is only capable of operating in /media.

OK, noted. It is still not "a general solution", which is my main point.

Regards.
--
Canek Peláez Valdés
Posgrado en Ciencia e Ingeniería de la Computación
Universidad Nacional Autónoma de México

Am 13.09.2012 16:19, schrieb Canek Peláez Valdés:

> The general solution is using something like udisks+polkit.

I have troubles with that combo for a month or so ... seems as if
polkit-0.107 somehow is responsible for stuff not mounted here.

~amd64 btw, gnome-3-context.

udisks comes (/is installed) in both slot 0 and 2, correct?

[i] sys-fs/udisks
Available versions:
(0) 1.0.4-r2 (~)1.0.4-r3
(2) (~)1.99.0 (~)1.99.0-r1

Does it work for all of you?

scratching my head ...

Stefan

On Thu, Sep 13, 2012 at 11:21 AM, Stefan G. Weichinger <lists@xunil.at> wrote:
> Am 13.09.2012 16:19, schrieb Canek Peláez Valdés:
>
>> The general solution is using something like udisks+polkit.
>
> I have troubles with that combo for a month or so ... seems as if
> polkit-0.107 somehow is responsible for stuff not mounted here.
>
> ~amd64 btw, gnome-3-context.
>
> udisks comes (/is installed) in both slot 0 and 2, correct?
>
> [i] sys-fs/udisks
> Available versions:
> (0) 1.0.4-r2 (~)1.0.4-r3
> (2) (~)1.99.0 (~)1.99.0-r1
>
> Does it work for all of you?

It doesn't, but I was under the assumption it was because I'm using
systemd. Since I installed gnome-shell-3.4 this has stopped working;
my findings can be seen on the bug to freedesktop.org:

https://bugs.freedesktop.org/show_bug.cgi?id=53905

It hits not only USB mounting; it also hits suspend/hibernate (I'm no
longer allowed to suspend as user), setting up printers, and basically
everything related to polkit. The root of the problem seems to be that
(somehow) gnome-shell gets registered as PolitUnixSession instead of
PolkitUnixProcess or PolkitSystemBusName, and that case is not covered
in subject_to_jsval.

Could you run polkitd without the --no-debug option (I don't have
OpenRC installed, nor /etc/init.d, so I don't know if that is how it's
run under OpenRC) and see on the logs if you see the following?

**
ERRORolkitbackendjsauthority.c:730:subject_to_js val: code should not be
reached

If so, please state it in the bug. David hasn't answered in three
weeks; two of them he was at the Kernel Summit in San Diego, but I
think it's time for me to nudge him again. An independent report
should help.

I'm running GNOME 3 unstable and with my systemd-only overlay, so I'm
used to this kind of things happening from time to time. Also, it has
easy workarounds (pmount, pm-suspend, etc.), so I haven't been really
concerned into fixing it.

Regards.
--
Canek Peláez Valdés
Posgrado en Ciencia e Ingeniería de la Computación
Universidad Nacional Autónoma de México