Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.user > #195676 > unrolled thread

Running GParted and Synaptic without entering password

Back to article view | Back to linux.debian.user

Contents

  Running GParted and Synaptic without entering password Richard Owlett <rowlett@cloud85.net> - 2018-05-13 15:40 +0200
    Re: Running GParted and Synaptic without entering password "tv.debian@googlemail.com" <tv.debian@googlemail.com> - 2018-05-13 16:20 +0200
      Re: Running GParted and Synaptic without entering password Richard Owlett <rowlett@cloud85.net> - 2018-05-13 21:50 +0200
        Re: Running GParted and Synaptic without entering password Joe <joe@jretrading.com> - 2018-05-14 10:00 +0200
          Re: Running GParted and Synaptic without entering password <tomas@tuxteam.de> - 2018-05-14 10:50 +0200
          Re: Running GParted and Synaptic without entering password Richard Owlett <rowlett@cloud85.net> - 2018-05-14 15:10 +0200
            Re: Running GParted and Synaptic without entering password David Wright <deblis@lionunicorn.co.uk> - 2018-05-15 02:50 +0200
              Re: Running GParted and Synaptic without entering password Richard Owlett <rowlett@cloud85.net> - 2018-05-15 13:30 +0200
                Re: Running GParted and Synaptic without entering password Curt <curty@free.fr> - 2018-05-15 14:50 +0200
                  Re: Running GParted and Synaptic without entering password Richard Owlett <rowlett@cloud85.net> - 2018-05-15 16:10 +0200
                Re: Running GParted and Synaptic without entering password David Wright <deblis@lionunicorn.co.uk> - 2018-05-15 19:00 +0200
                  Re: Running GParted and Synaptic without entering password Glenn English <ghe2001@gmail.com> - 2018-05-15 20:30 +0200
                    Re: Running GParted and Synaptic without entering password Joe <joe@jretrading.com> - 2018-05-16 11:30 +0200
          Re: Running GParted and Synaptic without entering password "John Crawley (johnraff)" <john@bunsenlabs.org> - 2018-05-15 07:50 +0200
            Re: Running GParted and Synaptic without entering password Richard Owlett <rowlett@cloud85.net> - 2018-05-15 15:30 +0200
              Re: Running GParted and Synaptic without entering password John Crawley <john@bunsenlabs.org> - 2018-05-16 07:40 +0200
                Re: Running GParted and Synaptic without entering password Richard Owlett <rowlett@cloud85.net> - 2018-05-16 09:50 +0200
    Re: Running GParted and Synaptic without entering password <tomas@tuxteam.de> - 2018-05-13 16:20 +0200
      Re: Running GParted and Synaptic without entering password Richard Owlett <rowlett@cloud85.net> - 2018-05-13 21:50 +0200
        Re: Running GParted and Synaptic without entering password David Wright <deblis@lionunicorn.co.uk> - 2018-05-14 03:30 +0200
        Re: Running GParted and Synaptic without entering password Richard Hector <richard@walnut.gen.nz> - 2018-05-14 08:00 +0200
          Re: Running GParted and Synaptic without entering password <tomas@tuxteam.de> - 2018-05-14 09:00 +0200
    Re: Running GParted and Synaptic without entering password bw <bwtnguy@yahoo.com> - 2018-05-13 16:30 +0200
      Re: Running GParted and Synaptic without entering password Richard Owlett <rowlett@cloud85.net> - 2018-05-13 22:00 +0200
        Re: Running GParted and Synaptic without entering password bw <bwtnguy@yahoo.com> - 2018-05-13 22:20 +0200
        Re: Running GParted and Synaptic without entering password <tomas@tuxteam.de> - 2018-05-14 09:20 +0200
          Re: Running GParted and Synaptic without entering password Richard Owlett <rowlett@cloud85.net> - 2018-05-14 15:40 +0200
    Re: Running GParted and Synaptic without entering password Brian <ad44@cityscape.co.uk> - 2018-05-14 01:10 +0200

Page 1 of 2  [1] 2  Next page →

#195676 — Running GParted and Synaptic without entering password

The underlying problem is not understanding what I read concerning sudo 
&/or /etc/sudoers (*INCLUDING* man pages).

Only *ONE* individual has physical access to my _personal_ machine.
Therefore, any distinction between 'richard' and 'root' is inherently 
artificial.

The result I wish to achieve is to click on the icon for either GParted 
or Synaptic *WITHOUT* being asked for a password (either root's or user's).

I've found vague hints that adding a line to my local /etc/sudoers file
such as
   richard     ALL = /usr/sbin/gparted , /usr/sbin/synaptic
would accomplish my goal.
Is that correct?

Also my reading suggested that adding myself to sudoers group would be 
required.

This has an undesired side effect. I'm asked for my user password 
instead of my root password. I currently have four different installs of 
Debian each having an intentionally identical sets of UID, GID, and 
passwords. No matter which install is active, if asked for an admin
password I want it to be the 'root password'

N.B.
My previous statement
> The result I wish to achive is to click on the icon for either
> GParted or Synaptic *WITHOUT* being asked for a password > (either root's or user's).
would apply only to the install on this partition.

[toc] | [next] | [standalone]

#195677

On 13/05/2018 18:48, Richard Owlett wrote:
> The underlying problem is not understanding what I read concerning sudo 
> &/or /etc/sudoers (*INCLUDING* man pages).
> 
> Only *ONE* individual has physical access to my _personal_ machine.
> Therefore, any distinction between 'richard' and 'root' is inherently 
> artificial.
> 
> The result I wish to achieve is to click on the icon for either GParted 
> or Synaptic *WITHOUT* being asked for a password (either root's or user's).
> 
> I've found vague hints that adding a line to my local /etc/sudoers file
> such as
>    richard     ALL = /usr/sbin/gparted , /usr/sbin/synaptic
> would accomplish my goal.
> Is that correct?
> 
> Also my reading suggested that adding myself to sudoers group would be 
> required.
> 
> This has an undesired side effect. I'm asked for my user password 
> instead of my root password. I currently have four different installs of 
> Debian each having an intentionally identical sets of UID, GID, and 
> passwords. No matter which install is active, if asked for an admin
> password I want it to be the 'root password'
> 
> N.B.
> My previous statement
>> The result I wish to achive is to click on the icon for either
>> GParted or Synaptic *WITHOUT* being asked for a password > (either 
>> root's or user's).
> would apply only to the install on this partition.
> 
> 
> 

Hello, to grant yourself "sudo" usage you can add your user to "sudo" 
group, or put this in your /etc/sudoers file:

$user ALL=(ALL:ALL) ALL

where you replace "$user" with your username.

To be granted password-less execution of a command you can use:

$user ALL=(ALL) NOPASSWD: /full/path/to/executable argument --option

The argument or options are of course optional, but for "NOPASSWD:" to 
work the command in /etc/sudoers must be the same as the one invoked by 
the user.

To be asked for root password all the time, use at the beginning of 
/etc/sudoers the line:

Defaults rootpw


You may still experience a different behavior for applications using the 
policykit framework.

It goes without saying that a specially crafted sudoers file can make 
your system much less secure, but you are the only judge of that.

Hope it helps.

[toc] | [prev] | [next] | [standalone]

#195685

On 05/13/2018 09:12 AM, tv.debian@googlemail.com wrote:
> On 13/05/2018 18:48, Richard Owlett wrote:
>> The underlying problem is not understanding what I read concerning 
>> sudo &/or /etc/sudoers (*INCLUDING* man pages).
>>
>> Only *ONE* individual has physical access to my _personal_ machine.
>> Therefore, any distinction between 'richard' and 'root' is inherently 
>> artificial.
>>
>> The result I wish to achieve is to click on the icon for either 
>> GParted or Synaptic *WITHOUT* being asked for a password (either 
>> root's or user's).
>>
>> I've found vague hints that adding a line to my local /etc/sudoers file
>> such as
>>    richard     ALL = /usr/sbin/gparted , /usr/sbin/synaptic
>> would accomplish my goal.
>> Is that correct?
>>
>> Also my reading suggested that adding myself to sudoers group would be 
>> required.
>>
>> This has an undesired side effect. I'm asked for my user password 
>> instead of my root password. I currently have four different installs 
>> of Debian each having an intentionally identical sets of UID, GID, and 
>> passwords. No matter which install is active, if asked for an admin
>> password I want it to be the 'root password'
>>
>> N.B.
>> My previous statement
>>> The result I wish to achive is to click on the icon for either
>>> GParted or Synaptic *WITHOUT* being asked for a password > (either 
>>> root's or user's).
>> would apply only to the install on this partition.
>>
>>
>>
> 
> Hello, to grant yourself "sudo" usage you can add your user to "sudo" 
> group, or put this in your /etc/sudoers file:
[snip]

Is "sudo" and cousins an appropriate tool?

Should I make myself a member of the group "LeRoi".
Members of "LeRoi" having inherent permission to run a finite set of 
programs.

CAVEAT LECTOR: bi-lingual pun ;/

[toc] | [prev] | [next] | [standalone]

#195699

On Sun, 13 May 2018 14:43:55 -0500
Richard Owlett <rowlett@cloud85.net> wrote:


> 
> Is "sudo" and cousins an appropriate tool?
> 
>

I would have said so. In order to make changes to a computer, both
GParted and Synaptic (and aptitude, apt-get etc.) *require* root
privileges. There's no way around that. The point about users running
without root privileges is explicitly to make them unable to make the
kind of changes to a computer that GParted and Synaptic do.

Both GParted and Synaptic are inherently graphical programs, requiring
the use of X, therefore their use in anger requires a mixture of root
and X. Anyone who doesn't like that idea is completely free to use
parted and aptitude.

If your micro-installation contains them, gksu and gksudo are graphical
equivalents of su and sudo. I start Synaptic from a menu entry, which
uses gksudo. It requires my password, because like the vast majority of
computers, all mine are usually connected to a network with Internet
access. If you want to use your computers in a different way from
almost everybody else, you must expect to do a certain amount of your
own trailblazing.

-- 
Joe

[toc] | [prev] | [next] | [standalone]

#195700

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Mon, May 14, 2018 at 08:56:47AM +0100, Joe wrote:
> On Sun, 13 May 2018 14:43:55 -0500
> Richard Owlett <rowlett@cloud85.net> wrote:
> 
> 
> > 
> > Is "sudo" and cousins an appropriate tool?

[...]

> If your micro-installation contains them, gksu and gksudo are graphical
> equivalents of su and sudo [...]

Exactly. That was the missing link on my side (I'm not a DE buff): gksudo
is what those tools need to integrate sudo with the Gnome-ish DEs.

Thanks
- -- tomás
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlr5TJkACgkQBcgs9XrR2kZXmACfTtKx1FG4MddlNW3Hbo8VKHcP
w7oAnRD6YqgndslbzWioV10YBMQ6ig/U
=Yeya
-----END PGP SIGNATURE-----

[toc] | [prev] | [next] | [standalone]

#195717

On 05/14/2018 02:56 AM, Joe wrote:
> On Sun, 13 May 2018 14:43:55 -0500
> Richard Owlett <rowlett@cloud85.net> wrote:
> 
> 
>>
>> Is "sudo" and cousins an appropriate tool?
>>
>>
> 
> I would have said so. In order to make changes to a computer, both
> GParted and Synaptic (and aptitude, apt-get etc.) *require* root
> privileges. There's no way around that.

I have no problem with that.

> The point about users running
> without root privileges is explicitly to make them unable to make the
> kind of changes to a computer that GParted and Synaptic do.

That's what I want for *ALL BUT ONE* of my systems.

> 
> Both GParted and Synaptic are inherently graphical programs, requiring
> the use of X, therefore their use in anger requires a mixture of root
> and X. Anyone who doesn't like that idea is completely free to use
> parted and aptitude.
> 
> If your micro-installation contains them, gksu and gksudo are graphical
> equivalents of su and sudo. I start Synaptic from a menu entry, which
> uses gksudo. It requires my password, because like the vast majority of
> computers, all mine are usually connected to a network with Internet
> access. If you want to use your computers in a different way from
> almost everybody else, you must expect to do a certain amount of your
> own trailblazing.
> 

Only 1 of the four machines within arm's reach are physically capable of 
connecting to the internet. Is there a way to block internet access for 
members of one group - similar to how "dialout" might have been used 
when connectivity was a 56k modem?

[toc] | [prev] | [next] | [standalone]

#195752

On Mon 14 May 2018 at 08:01:05 (-0500), Richard Owlett wrote:

> Only 1 of the four machines within arm's reach are physically
> capable of connecting to the internet. Is there a way to block
> internet access for members of one group - similar to how "dialout"
> might have been used when connectivity was a 56k modem?

AFAIK group dialout gives you access to the serial ports with their
modems, and dip gives you access to ppp's configuration files. These
enable you to configure and instigate connections, but that never
had any effect on users, who can all use the IP link once it's up.

To block a group, I think you'd have to use a packet filter to
drop their outgoing packets. Take a look at
http://ipset.netfilter.org/iptables-extensions.man.html
under the heading "owner".

OTOH it's easy to voluntarily block some browsers from being able
to make non-local connections, eg:   lynx -localhost

Cheers,
David.

[toc] | [prev] | [next] | [standalone]

#195764

On 05/14/2018 07:40 PM, David Wright wrote:
> On Mon 14 May 2018 at 08:01:05 (-0500), Richard Owlett wrote:
> 
>> Only 1 of the four machines within arm's reach are physically
>> capable of connecting to the internet. Is there a way to block
>> internet access for members of one group - similar to how "dialout"
>> might have been used when connectivity was a 56k modem?
> 
> AFAIK group dialout gives you access to the serial ports with their
> modems, and dip gives you access to ppp's configuration files. These
> enable you to configure and instigate connections,

Was there a companion tool do a forced disconnect?
I use a USB connected T-Mobile hotspot with WiFi disabled.
It currently appears to the system as /dev/sdb .
Is there a way to enable/disable access to that device?

> but that never
> had any effect on users, who can all use the IP link once it's up.
> 
> To block a group, I think you'd have to use a packet filter to
> drop their outgoing packets. Take a look at
> http://ipset.netfilter.org/iptables-extensions.man.html
> under the heading "owner".

That gives just enough information to tantalize ;[
What should I search for to see a sample use.
My only iptable knowledge is that they exist.

> 
> OTOH it's easy to voluntarily block some browsers from being able
> to make non-local connections, eg:   lynx -localhost

I've not seen anything useful in that vein with SeaMonkey.
It defaults to giving web access with an option to later view only local 
files.

> 
> Cheers,
> David.
> 
> 

[toc] | [prev] | [next] | [standalone]

#195768

On 2018-05-15, Richard Owlett <rowlett@cloud85.net> wrote:

>> To block a group, I think you'd have to use a packet filter to
>> drop their outgoing packets. Take a look at
>> http://ipset.netfilter.org/iptables-extensions.man.html
>> under the heading "owner".
>
> That gives just enough information to tantalize ;[
> What should I search for to see a sample use.
> My only iptable knowledge is that they exist.
>

Apparently you can create a group:

 sudo groupadd nonetty

Add existing user 'lydia'(and anyone else you'd like) to the group

 sudo usermod -a -G nonetty lydia

Then an iptables rule like this

 iptables -I OUTPUT 1 -m owner --gid-owner nonetty -j DROP

would prevent lydia (and others in the nonetty group) from riding
the innertubes.

I believe. More well-informed minds might pipe up or chime in at
this point, who knows?

(I'm looking at the link above without instantaneous edification, BTW.)

[toc] | [prev] | [next] | [standalone]

#195770

On 05/15/2018 07:37 AM, Curt wrote:
> On 2018-05-15, Richard Owlett <rowlett@cloud85.net> wrote:
> 
>>> To block a group, I think you'd have to use a packet filter to
>>> drop their outgoing packets. Take a look at
>>> http://ipset.netfilter.org/iptables-extensions.man.html
>>> under the heading "owner".
>>
>> That gives just enough information to tantalize ;[
>> What should I search for to see a sample use.
>> My only iptable knowledge is that they exist.
>>
> 
> Apparently you can create a group:
> 
>   sudo groupadd nonetty
> 
> Add existing user 'lydia'(and anyone else you'd like) to the group
> 
>   sudo usermod -a -G nonetty lydia
> 
> Then an iptables rule like this
> 
>   iptables -I OUTPUT 1 -m owner --gid-owner nonetty -j DROP
> 
> would prevent lydia (and others in the nonetty group) from riding
> the innertubes.
> 
> I believe. More well-informed minds might pipe up or chime in at
> this point, who knows?
> 
> (I'm looking at the link above without instantaneous edification, BTW.)
> 
> 

Thank you.
I'll sit down with the iptables man page to parse your suggested rule.

Since I posted, I have:
1. (re?)discovered that the USB connected T-Mobile hotspot used
     appears to system as "ETHERNET - wired connection1".
     The associated screen displays several things to explore which
     may be useful.
2. found
  [https://www.freedesktop.org/software/polkit/docs/latest/polkit.8.html]
  Its last example may be useful to deal with gparted.

[toc] | [prev] | [next] | [standalone]

#195774

On Tue 15 May 2018 at 06:20:17 (-0500), Richard Owlett wrote:
> On 05/14/2018 07:40 PM, David Wright wrote:
> >On Mon 14 May 2018 at 08:01:05 (-0500), Richard Owlett wrote:
> >
> >>Only 1 of the four machines within arm's reach are physically
> >>capable of connecting to the internet. Is there a way to block
> >>internet access for members of one group - similar to how "dialout"
> >>might have been used when connectivity was a 56k modem?
> >
> >AFAIK group dialout gives you access to the serial ports with their
> >modems, and dip gives you access to ppp's configuration files. These
> >enable you to configure and instigate connections,
> 
> Was there a companion tool do a forced disconnect?

The same group could stop links as well as start them. But the easy
way with a modem is for ANOther to just switch it off.

[…]

> >OTOH it's easy to voluntarily block some browsers from being able
> >to make non-local connections, eg:   lynx -localhost
> 
> I've not seen anything useful in that vein with SeaMonkey.
> It defaults to giving web access with an option to later view only
> local files.

You could look for ideas in pages like
https://www.ghacks.net/2012/02/15/how-to-turn-chrome-or-firefox-into-a-single-site-browser/
where your site would be localhost.

Cheers,
David.

[toc] | [prev] | [next] | [standalone]

#195776

When I've logged in as a mortal to my XFCE GUI, I can just type, in
the terminal emulator, 'sudo gparted' and the GUI comes up and works
like I expect it to. After I quit gparted, there's some stuff it's
written on the screen (I've never tried to figure out what it's
about).

I haven't tried that with Synaptic, but I'd be surprised if it whined.
I know 'sudo aptitude' works, but CLI tools are what sudo's for.

Oh, and I've got sudo configured so it doesn't ask me for a password...

-- 
Glenn English

[toc] | [prev] | [next] | [standalone]

#195788

On Tue, 15 May 2018 18:27:20 +0000
Glenn English <ghe2001@gmail.com> wrote:

> When I've logged in as a mortal to my XFCE GUI, I can just type, in
> the terminal emulator, 'sudo gparted' and the GUI comes up and works
> like I expect it to. After I quit gparted, there's some stuff it's
> written on the screen (I've never tried to figure out what it's
> about).
> 
> I haven't tried that with Synaptic, but I'd be surprised if it whined.
> I know 'sudo aptitude' works, but CLI tools are what sudo's for.

You can run any program that way, once you know what file launches it.
It is how you begin debugging a faulty GUI app, the stuff left behind
when it closes may be useful. Or it may just be GTK garbage...

-- 
Joe 

[toc] | [prev] | [next] | [standalone]

#195757

On 2018-05-14 16:56, Joe wrote:
> On Sun, 13 May 2018 14:43:55 -0500
> If your micro-installation contains them, gksu and gksudo are graphical
> equivalents of su and sudo. I start Synaptic from a menu entry, which
> uses gksudo.

gksu is now deprecated as insecure,
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=892768
and will not be available in Debian Buster as far as I can see.
https://packages.debian.org/search?keywords=gksu&searchon=names&suite=all&section=all

Even on Stretch and (I think) Wheezy, Gparted and Synaptic both shipped  
.desktop files which caused them to be launched by the policykit  
alternative, pkexec instead of gksu.

Policykit brings its own complications, but I think it should be  
possible to create a .pkla file in /var/lib/polkit-1/localauthority to  
allow a certain user, or group member, to perform an action defined in  
/usr/share/polkit-1/actions/* without a password. You could even add a  
new action if necessary.

See also: http://forums.debian.net/viewtopic.php?f=19&t=137326

-- 
John

[toc] | [prev] | [next] | [standalone]

#195769

On 05/15/2018 12:48 AM, John Crawley (johnraff) wrote:
> On 2018-05-14 16:56, Joe wrote:
>> On Sun, 13 May 2018 14:43:55 -0500
>> If your micro-installation contains them, gksu and gksudo are graphical
>> equivalents of su and sudo. I start Synaptic from a menu entry, which
>> uses gksudo.
> 
> gksu is now deprecated as insecure,
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=892768
> and will not be available in Debian Buster as far as I can see.
> https://packages.debian.org/search?keywords=gksu&searchon=names&suite=all&section=all 
> 
> 
> Even on Stretch and (I think) Wheezy, Gparted and Synaptic both shipped 
> .desktop files which caused them to be launched by the policykit 
> alternative, pkexec instead of gksu.
> 
> Policykit brings its own complications, but I think it should be 
> possible to create a .pkla file in /var/lib/polkit-1/localauthority to 
> allow a certain user, or group member, to perform an action defined in 
> /usr/share/polkit-1/actions/* without a password. You could even add a 
> new action if necessary.

Through a chain of references I discovered
   /usr/share/polkit-1/actions/com.ubuntu.pkexec.gparted.policy

The initial lines read:
> <?xml version="1.0" encoding="UTF-8"?>
> <!DOCTYPE policyconfig PUBLIC
>  "-//freedesktop//DTD PolicyKit Policy Configuration 1.0//EN"
>  "http://www.freedesktop.org/standards/PolicyKit/1/policyconfig.dtd">
> <policyconfig>

However
   [http://www.freedesktop.org/standards/PolicyKit/1/policyconfig.dtd]
gives a 404 File not found message.

Where would I find its syntax?

By a convoluted path I found:
[https://www.freedesktop.org/software/polkit/docs/latest/polkit.8.html]

Its last example strongly suggests I can do just what I want without  
messing up other users &/or apps.

Is there an equivalent of that content in Backus–Naur form?

[toc] | [prev] | [next] | [standalone]

#195784

On 2018-05-15 22:24, Richard Owlett wrote:
> On 05/15/2018 12:48 AM, John Crawley (johnraff) wrote:
>>
>> Policykit brings its own complications, but I think it should be 
>> possible to create a .pkla file in /var/lib/polkit-1/localauthority to 
>> allow a certain user, or group member, to perform an action defined in 
>> /usr/share/polkit-1/actions/* without a password. You could even add a 
>> new action if necessary.
> 
> Through a chain of references I discovered
>    /usr/share/polkit-1/actions/com.ubuntu.pkexec.gparted.policy
> 
> The initial lines read:
>> <?xml version="1.0" encoding="UTF-8"?>
>> <!DOCTYPE policyconfig PUBLIC
>>  "-//freedesktop//DTD PolicyKit Policy Configuration 1.0//EN"
>>  "http://www.freedesktop.org/standards/PolicyKit/1/policyconfig.dtd">
>> <policyconfig>
> 
> However
>    [http://www.freedesktop.org/standards/PolicyKit/1/policyconfig.dtd]
> gives a 404 File not found message.

Indeed. Even so, that seems to be what is required in the xml.

> Where would I find its syntax?

I had a similar problem a while ago and found internet searches to be 
somewhat helpful.
This is not Debian, but on-topic:
https://wiki.archlinux.org/index.php/Polkit
And:
https://www.freedesktop.org/software/polkit/docs/0.105/pklocalauthority.8.html
http://davidz25.blogspot.jp/2012/06/authorization-rules-in-polkit.html
https://github.com/systemd/systemd/issues/5523

It seems polkit want to shift from .pkla files to (javascript-like) 
.rules files, but at the moment both might work on Debian, so use 
whichever you feel less uncomfortable with.

I used a .pkla file in /var/lib/polkit-1/localauthority/10-vendor.d/. If 
you search for *.pkla files on your system, there might be some there, 
or in /etc/polkit-1/localauthority/* to use as a template.

> By a convoluted path I found:
> [https://www.freedesktop.org/software/polkit/docs/latest/polkit.8.html]
> 
> Its last example strongly suggests I can do just what I want without 
> messing up other users &/or apps.

That's what I think too. Just as an untested guess, since the action is 
already defined, something like this in 
/etc/polkit-1/localauthority/50-local.d/gparted.pkla?

[Allow specific user to use gparted]
Identity=unix-user:yourusername
Action=com.ubuntu.pkexec.gparted
ResultAny=no
ResultInactive=no
ResultActive=yes

BTW To see the currently defined actions on your system, try this:
cat /usr/share/polkit-1/actions/* | grep -E 
'(<action|<description>|<message>|<allow|</action>)'|sed 
's/<\/action>/\n/g;s/<\/[^>]*>//g'
But you can add one of your own too.

-- 
John

[toc] | [prev] | [next] | [standalone]

#195787

On 05/16/2018 12:36 AM, John Crawley wrote:
> On 2018-05-15 22:24, Richard Owlett wrote:
>> On 05/15/2018 12:48 AM, John Crawley (johnraff) wrote:
>>>
>>> Policykit brings its own complications, but I think it should be 
>>> possible to create a .pkla file in /var/lib/polkit-1/localauthority 
>>> to allow a certain user, or group member, to perform an action 
>>> defined in /usr/share/polkit-1/actions/* without a password. You 
>>> could even add a new action if necessary.
>>
>> Through a chain of references I discovered
>>    /usr/share/polkit-1/actions/com.ubuntu.pkexec.gparted.policy
>>
>> The initial lines read:
>>> <?xml version="1.0" encoding="UTF-8"?>
>>> <!DOCTYPE policyconfig PUBLIC
>>>  "-//freedesktop//DTD PolicyKit Policy Configuration 1.0//EN"
>>>  "http://www.freedesktop.org/standards/PolicyKit/1/policyconfig.dtd">
>>> <policyconfig>
>>
>> However
>>    [http://www.freedesktop.org/standards/PolicyKit/1/policyconfig.dtd]
>> gives a 404 File not found message.
> 
> Indeed. Even so, that seems to be what is required in the xml.
> 
>> Where would I find its syntax?
> 
> I had a similar problem a while ago and found internet searches to be 
> somewhat helpful.

My searches were not as good. Thank you.

> This is not Debian, but on-topic:
> https://wiki.archlinux.org/index.php/Polkit
> And:
> https://www.freedesktop.org/software/polkit/docs/0.105/pklocalauthority.8.html 
> 
> http://davidz25.blogspot.jp/2012/06/authorization-rules-in-polkit.html
> https://github.com/systemd/systemd/issues/5523

I don't know if they answer ALL my questions.
BUT they each specifically address one or more of my questions.
They also suggest some likely fruitful search terms.

> 
> It seems polkit want to shift from .pkla files to (javascript-like) 
> .rules files, but at the moment both might work on Debian, so use 
> whichever you feel less uncomfortable with.
> 
> I used a .pkla file in /var/lib/polkit-1/localauthority/10-vendor.d/. If 
> you search for *.pkla files on your system, there might be some there, 
> or in /etc/polkit-1/localauthority/* to use as a template.
> 
>> By a convoluted path I found:
>> [https://www.freedesktop.org/software/polkit/docs/latest/polkit.8.html]
>>
>> Its last example strongly suggests I can do just what I want without 
>> messing up other users &/or apps.
> 
> That's what I think too. Just as an untested guess, since the action is 
> already defined, something like this in 
> /etc/polkit-1/localauthority/50-local.d/gparted.pkla?
> 
> [Allow specific user to use gparted]
> Identity=unix-user:yourusername
> Action=com.ubuntu.pkexec.gparted
> ResultAny=no
> ResultInactive=no
> ResultActive=yes
> 
> BTW To see the currently defined actions on your system, try this:
> cat /usr/share/polkit-1/actions/* | grep -E 
> '(<action|<description>|<message>|<allow|</action>)'|sed 
> 's/<\/action>/\n/g;s/<\/[^>]*>//g'
> But you can add one of your own too.
> 

[toc] | [prev] | [next] | [standalone]

#195678

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Sun, May 13, 2018 at 08:18:26AM -0500, Richard Owlett wrote:
> The underlying problem is not understanding what I read concerning
> sudo &/or /etc/sudoers (*INCLUDING* man pages).
> 
> Only *ONE* individual has physical access to my _personal_ machine.
> Therefore, any distinction between 'richard' and 'root' is
> inherently artificial.

Not so fast. A small flaw in your browser might allow it to run as
you and try some shenanigan as root: you'd notice it by "something"
asking for your credentials unexpectedly...

> The result I wish to achieve is to click on the icon for either
> GParted or Synaptic *WITHOUT* being asked for a password (either
> root's or user's).
> 
> I've found vague hints that adding a line to my local /etc/sudoers file
> such as
>   richard     ALL = /usr/sbin/gparted , /usr/sbin/synaptic
> would accomplish my goal.
> Is that correct?
> 
> Also my reading suggested that adding myself to sudoers group would
> be required.
> 
> This has an undesired side effect. I'm asked for my user password
> instead of my root password. I currently have four different
> installs of Debian each having an intentionally identical sets of
> UID, GID, and passwords. No matter which install is active, if asked
> for an admin
> password I want it to be the 'root password'

Assuming your desktop environment plays well along with sudo (I
think the Gnome derivatives do, but I'll leave that answer to
someone more versed in that) see the manpage for sudoers:


   User Authentication
     The sudoers security policy requires that most users
     authenticate themselves before they can use sudo.  A password
     is not required if the invoking user is root, if the target
     user is the same as the invoking user, or if the policy has
     disabled authentication for the user or command.  Unlike
     su(1), when sudoers requires authentication, it validates
     the invoking user's credentials, not the target user's (or
     root's) credentials.  This can be changed via the rootpw,
     targetpw and runaspw flags, described later.

So setting up a default line like so:

  Defaults rootpw

would ask by default for the root password or (more specifically)

  Defaults:richard rootpw

would limit that default to richard. For no password:

  Defaults:richard !authenticate

For single commands there is the equivalent NOPASSWD tag. Your line
above would read

  richard  NOPASSWD: ALL = /usr/sbin/gparted , /usr/sbin/synaptic

(which perhaps wouldn't do what you want: that would allow you to
run "sudo synaptic" as root without being asked for a password, but
you'd (a) not want to run synaptic as root and (b) possibly run
into the next problem that perhaps root doesn't find the X server...)

- -- t
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEYEARECAAYFAlr4RysACgkQBcgs9XrR2kZuqQCfWsWrvqshup8ihXTx5H1wU0O8
YwYAn1m778zx/DyTTAbypgA02ORLxGVF
=ZVYn
-----END PGP SIGNATURE-----

[toc] | [prev] | [next] | [standalone]

#195686

On 05/13/2018 09:09 AM, tomas@tuxteam.de wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> On Sun, May 13, 2018 at 08:18:26AM -0500, Richard Owlett wrote:
>> The underlying problem is not understanding what I read concerning
>> sudo &/or /etc/sudoers (*INCLUDING* man pages).
>>
>> Only *ONE* individual has physical access to my _personal_ machine.
>> Therefore, any distinction between 'richard' and 'root' is
>> inherently artificial.
> 
> Not so fast. A small flaw in your browser might allow it to run as
> you and try some shenanigan as root: you'd notice it by "something"
> asking for your credentials unexpectedly...

You have moths in your logic (cf. 
https://en.wikipedia.org/wiki/Grace_Hopper):
   Moth, the first:
       When asked for unexpected permission, "Just say NO"
       [If doubtful, then dirty ;]
   Moth, the second:
       What if I had been logged in as root?

> 
>> The result I wish to achieve is to click on the icon for either
>> GParted or Synaptic *WITHOUT* being asked for a password (either
>> root's or user's).
>>
>> I've found vague hints that adding a line to my local /etc/sudoers file
>> such as
>>    richard     ALL = /usr/sbin/gparted , /usr/sbin/synaptic
>> would accomplish my goal.
>> Is that correct?
>>
>> Also my reading suggested that adding myself to sudoers group would
>> be required.
>>
>> This has an undesired side effect. I'm asked for my user password
>> instead of my root password. I currently have four different
>> installs of Debian each having an intentionally identical sets of
>> UID, GID, and passwords. No matter which install is active, if asked
>> for an admin
>> password I want it to be the 'root password'
> 
> Assuming your desktop environment plays well along with sudo (I
> think the Gnome derivatives do, but I'll leave that answer to
> someone more versed in that) see the manpage for sudoers:

It was only a WAG (wild a????? guess) that sudo might be appropriate ;}

> 
> 
>     User Authentication
>       The sudoers security policy requires that most users
>       authenticate themselves before they can use sudo.  A password
>       is not required if the invoking user is root, if the target
>       user is the same as the invoking user, or if the policy has
>       disabled authentication for the user or command.  Unlike
>       su(1), when sudoers requires authentication, it validates
>       the invoking user's credentials, not the target user's (or
>       root's) credentials.  This can be changed via the rootpw,
>       targetpw and runaspw flags, described later.

*ROFL*
That paragraph was one of the explicit reasons I wrote:> The underlying 
problem is not understanding what I read concerning sudo
> &/or /etc/sudoers (*INCLUDING* man pages). 

CAVEAT LECTORS:
I have a history of problems asking questions on this forum:
   1. I prefer to ask narrowly focused questions.
      That gets response "Tell us more".
   2. If my original question has details, the responses I get can be
      summed up by somebody's signature tag line -"Universal advice --
      DON'T do that". [should that *ROFL* or "weep weep"?]

P.S.    You have been saved from a plethora of bad puns.
P.P.S.  I've read several articles on "how to ask questions".
         None address my balancing act quandary ;/

*P.P.P.S.*
A definite thank you to all who attempt to answer my questions ;)

[toc] | [prev] | [next] | [standalone]

#195694

On Sun 13 May 2018 at 14:44:14 (-0500), Richard Owlett wrote:
> On 05/13/2018 09:09 AM, tomas@tuxteam.de wrote:
> >-----BEGIN PGP SIGNED MESSAGE-----
> >Hash: SHA1
> >
> >On Sun, May 13, 2018 at 08:18:26AM -0500, Richard Owlett wrote:
> >>The underlying problem is not understanding what I read concerning
> >>sudo &/or /etc/sudoers (*INCLUDING* man pages).
> >>
> >>Only *ONE* individual has physical access to my _personal_ machine.
> >>Therefore, any distinction between 'richard' and 'root' is
> >>inherently artificial.
> >
> >Not so fast. A small flaw in your browser might allow it to run as
> >you and try some shenanigan as root: you'd notice it by "something"
> >asking for your credentials unexpectedly...
> 
> You have moths in your logic (cf.
> https://en.wikipedia.org/wiki/Grace_Hopper):
>   Moth, the first:
>       When asked for unexpected permission, "Just say NO"
>       [If doubtful, then dirty ;]
>   Moth, the second:
>       What if I had been logged in as root?

Then why worry about running synaptic yourself? Every compromised site
you visit will be installing software on your machine and taking it over.
Sit back, watch the action, or go and find your installation CD.

I think we've been here before …

>   2. If my original question has details, the responses I get can be
>      summed up by somebody's signature tag line -"Universal advice --
>      DON'T do that".

That's right.

Cheers,
David.

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | linux.debian.user

csiph-web