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

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

parted is ALMOST suitable

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

Contents

  parted is ALMOST suitable Richard Owlett <rowlett@cloud85.net> - 2016-11-07 13:20 +0100
    Re: parted is ALMOST suitable Felipe Salvador <felipe.salvador@gmail.com> - 2016-11-07 13:30 +0100
      Re: parted is ALMOST suitable Richard Owlett <rowlett@cloud85.net> - 2016-11-07 13:40 +0100
        Re: parted is ALMOST suitable <tomas@tuxteam.de> - 2016-11-07 14:00 +0100
          Re: parted is ALMOST suitable Richard Owlett <rowlett@cloud85.net> - 2016-11-07 14:20 +0100
            Re: parted is ALMOST suitable <tomas@tuxteam.de> - 2016-11-07 15:00 +0100
              Re: parted is ALMOST suitable Richard Owlett <rowlett@cloud85.net> - 2016-11-07 15:50 +0100
                Re: parted is ALMOST suitable <tomas@tuxteam.de> - 2016-11-07 16:10 +0100
                Re: parted is ALMOST suitable Lisi Reisz <lisi.reisz@gmail.com> - 2016-11-07 17:30 +0100
        Re: parted is ALMOST suitable Felipe Salvador <felipe.salvador@gmail.com> - 2016-11-07 15:30 +0100
          Re: parted is ALMOST suitable Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2016-11-07 16:20 +0100
            Re: parted is ALMOST suitable Aldo Maggi <aldomaggi@katamail.com> - 2016-11-07 18:20 +0100
            Re: parted is ALMOST suitable Felipe Salvador <felipe.salvador@gmail.com> - 2016-11-07 19:00 +0100
            Re: parted is ALMOST suitable Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2016-11-08 19:10 +0100
              Re: parted is ALMOST suitable Glenn English <ghe2001@gmail.com> - 2016-11-08 19:40 +0100
                Re: parted is ALMOST suitable Stefan Monnier <monnier@iro.umontreal.ca> - 2016-11-08 21:10 +0100
                  Re: parted is ALMOST suitable Brian <ad44@cityscape.co.uk> - 2016-11-08 21:50 +0100
                    Re: parted is ALMOST suitable Stefan Monnier <monnier@iro.umontreal.ca> - 2016-11-09 00:20 +0100
                      Re: parted is ALMOST suitable Brian <ad44@cityscape.co.uk> - 2016-11-09 18:40 +0100
                        Re: parted is ALMOST suitable <tomas@tuxteam.de> - 2016-11-09 21:40 +0100
                          Re: parted is ALMOST suitable Brian <ad44@cityscape.co.uk> - 2016-11-09 21:50 +0100
                            Re: parted is ALMOST suitable <tomas@tuxteam.de> - 2016-11-09 22:20 +0100
                    Re: parted is ALMOST suitable <tomas@tuxteam.de> - 2016-11-09 09:50 +0100
                      Re: parted is ALMOST suitable Brian <ad44@cityscape.co.uk> - 2016-11-09 11:20 +0100
                        Re: parted is ALMOST suitable <tomas@tuxteam.de> - 2016-11-09 11:30 +0100
                          Re: parted is ALMOST suitable Brian <ad44@cityscape.co.uk> - 2016-11-09 11:50 +0100
                            Re: parted is ALMOST suitable <tomas@tuxteam.de> - 2016-11-09 12:10 +0100
                              Re: parted is ALMOST suitable Brian <ad44@cityscape.co.uk> - 2016-11-09 17:10 +0100
                          Re: parted is ALMOST suitable Richard Owlett <rowlett@cloud85.net> - 2016-11-09 15:20 +0100
                            Re: parted is ALMOST suitable Brian <ad44@cityscape.co.uk> - 2016-11-09 20:50 +0100
                              Re: parted is ALMOST suitable Richard Owlett <rowlett@cloud85.net> - 2016-11-09 21:40 +0100
                          Re: parted is ALMOST suitable Brian <ad44@cityscape.co.uk> - 2016-11-09 21:10 +0100
                            Re: parted is ALMOST suitable Joe Pfeiffer <pfeiffer@cs.nmsu.edu> - 2016-11-10 01:20 +0100
                              Re: parted is ALMOST suitable <tomas@tuxteam.de> - 2016-11-10 10:10 +0100
                      Re: parted is ALMOST suitable Brian <ad44@cityscape.co.uk> - 2016-11-09 19:30 +0100
                        Re: parted is ALMOST suitable <tomas@tuxteam.de> - 2016-11-09 21:40 +0100
                  Re: parted is ALMOST suitable Stefan Monnier <monnier@iro.umontreal.ca> - 2016-11-08 22:10 +0100
                    Re: parted is ALMOST suitable Lisi Reisz <lisi.reisz@gmail.com> - 2016-11-09 16:00 +0100
                  Re: parted is ALMOST suitable <tomas@tuxteam.de> - 2016-11-09 09:40 +0100
          Re: parted is ALMOST suitable Richard Owlett <rowlett@cloud85.net> - 2016-11-07 16:30 +0100
            Re: parted is ALMOST suitable Brian <ad44@cityscape.co.uk> - 2016-11-07 17:10 +0100
              Re: parted is ALMOST suitable Felipe Salvador <felipe.salvador@gmail.com> - 2016-11-07 18:50 +0100
                Re: parted is ALMOST suitable Brian <ad44@cityscape.co.uk> - 2016-11-07 20:20 +0100
                  Re: parted is ALMOST suitable Lisi Reisz <lisi.reisz@gmail.com> - 2016-11-08 00:50 +0100
                    Re: parted is ALMOST suitable Brian <ad44@cityscape.co.uk> - 2016-11-08 01:40 +0100
                    Re: parted is ALMOST suitable Michael Lange <klappnase@freenet.de> - 2016-11-08 03:50 +0100
                      Re: parted is ALMOST suitable Richard Owlett <rowlett@cloud85.net> - 2016-11-08 12:00 +0100
                        Correction - Re: parted is ALMOST suitable Richard Owlett <rowlett@cloud85.net> - 2016-11-08 12:20 +0100
                          Re: Correction - Re: parted is ALMOST suitable Brian <ad44@cityscape.co.uk> - 2016-11-08 20:30 +0100
                        Re: parted is ALMOST suitable David Wright <deblis@lionunicorn.co.uk> - 2016-11-08 13:50 +0100
                          Re: parted is ALMOST suitable Brian <ad44@cityscape.co.uk> - 2016-11-08 20:10 +0100
    Re: parted is ALMOST suitable Frank <zuiderduin@gmx.com> - 2016-11-07 13:30 +0100
    Re: parted is ALMOST suitable Darac Marjal <mailinglist@darac.org.uk> - 2016-11-07 13:40 +0100
    Re: parted is ALMOST suitable <tomas@tuxteam.de> - 2016-11-07 13:50 +0100
      Re: parted is ALMOST suitable Richard Owlett <rowlett@cloud85.net> - 2016-11-07 14:30 +0100
        Re: parted is ALMOST suitable <tomas@tuxteam.de> - 2016-11-07 15:10 +0100
        Re: parted is ALMOST suitable Richard Owlett <rowlett@cloud85.net> - 2016-11-07 15:20 +0100
          Re: parted is ALMOST suitable Greg Wooledge <wooledg@eeg.ccf.org> - 2016-11-07 15:30 +0100
            Re: parted is ALMOST suitable <tomas@tuxteam.de> - 2016-11-07 15:40 +0100
            Re: parted is ALMOST suitable Richard Owlett <rowlett@cloud85.net> - 2016-11-07 17:00 +0100
              Re: parted is ALMOST suitable Greg Wooledge <wooledg@eeg.ccf.org> - 2016-11-07 17:10 +0100
                Re: parted is ALMOST suitable Nicolas George <george@nsup.org> - 2016-11-07 17:20 +0100
          Re: parted is ALMOST suitable <tomas@tuxteam.de> - 2016-11-07 15:30 +0100
            Re: parted is ALMOST suitable Greg Wooledge <wooledg@eeg.ccf.org> - 2016-11-07 15:40 +0100
              Re: parted is ALMOST suitable <tomas@tuxteam.de> - 2016-11-07 16:10 +0100
                Re: parted is ALMOST suitable Reco <recoverym4n@gmail.com> - 2016-11-07 18:00 +0100
                  Re: parted is ALMOST suitable <tomas@tuxteam.de> - 2016-11-08 10:20 +0100
          Re: parted is ALMOST suitable Pascal Hambourg <pascal@plouf.fr.eu.org> - 2016-11-07 21:10 +0100
            Re: parted is ALMOST suitable Brian <ad44@cityscape.co.uk> - 2016-11-08 01:00 +0100
              Re: parted is ALMOST suitable Richard Owlett <rowlett@cloud85.net> - 2016-11-08 12:20 +0100
              Re: parted is ALMOST suitable Pascal Hambourg <pascal@plouf.fr.eu.org> - 2016-11-11 15:40 +0100
                Re: parted is ALMOST suitable Brian <ad44@cityscape.co.uk> - 2016-11-11 17:30 +0100
                  Re: parted is ALMOST suitable Pascal Hambourg <pascal@plouf.fr.eu.org> - 2016-11-11 18:10 +0100
                    Re: parted is ALMOST suitable Brian <ad44@cityscape.co.uk> - 2016-11-11 18:40 +0100
      Re: parted is ALMOST suitable David Wright <deblis@lionunicorn.co.uk> - 2016-11-07 15:10 +0100
        Re: parted is ALMOST suitable <tomas@tuxteam.de> - 2016-11-07 15:10 +0100
    Re: parted is ALMOST suitable rhkramer@gmail.com - 2016-11-07 15:00 +0100

Page 4 of 4 — ← Prev page 1 2 3 [4]

#174313

On Mon, Nov 07, 2016 at 09:57:14AM -0600, Richard Owlett wrote:
> In any case, off-list someone suggested using
>    /sbin/blkid /dev/sda*
> That works. *BUT* I wonder about unknown implications of "/sbin" 
> being required if not explicitly running as root.

It's simply because /sbin is not in your default PATH as a regular user.
Most of the commands in /sbin require root privileges to do their jobs,
but there are a few that don't, at least for certain limited parts of
their jobs.  (/sbin/ifconfig is probably the most famous.)

If you want to run this command without root privileges, you can add
/sbin to your PATH.  This is not a security problem.  It's just that most
regular users don't need these commands.  There is a minuscule decrease
in efficiency when another directory in PATH has to be searched, but
it's probably not going to be noticeable.

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

#174315

[Multipart message — attachments visible in raw view] — view raw

Le septidi 17 brumaire, an CCXXV, Greg Wooledge a écrit :
>					    There is a minuscule decrease
> in efficiency when another directory in PATH has to be searched, but
> it's probably not going to be noticeable.

What will be noticeable, though, it the namespace pollution. For people
using autocompletion extensively, adding hundreds of commands in the
PATH has a very visible consequence, often requiring re-learning a few
common keystrokes.

Regards,

-- 
  Nicolas George

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

#174300

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

On Mon, Nov 07, 2016 at 08:18:28AM -0600, Richard Owlett wrote:
> On 11/7/2016 7:25 AM, Richard Owlett wrote:
> >On 11/7/2016 6:47 AM, tomas@tuxteam.de wrote:
> >>-----BEGIN PGP SIGNED MESSAGE-----
> >>Hash: SHA1
> >>
> >>On Mon, Nov 07, 2016 at 06:11:50AM -0600, Richard Owlett wrote:
> >>>I need to identify file system on all partitions of my hard drive
> >>>whether mounted or not.
> >>>     parted /dev/sda print | grep ext | grep -v exte
> >>>reports the desired information [partitions formatted ext?] in a
> >>>convenient format.
> >>>*HOWEVER* parted requires root privileges. That is not
> >>>acceptable.
> >>>Suggestions?
> >>
> >>It's not parted. It's the partitions themselves (or more
> >>accurately,
> >>the devices via which your operating system makes the partitions
> >>available to user space). By default (and there are some reasons
> >>for it) they're not readable by everyone. They are writable by
> >>even less. On my box, for example:
> >>
> >>   tomas@rasputin:~$ ls -al /dev/sd*
> >>   brw-rw---- 1 root disk 8, 0 Nov  7 09:06 /dev/sda
> >>   brw-rw---- 1 root disk 8, 1 Nov  7 09:06 /dev/sda1
> >>   brw-rw---- 1 root disk 8, 2 Nov  7 09:06 /dev/sda2
> >>   brw-rw---- 1 root disk 8, 5 Nov  7 09:06 /dev/sda5
> >>
> >>So you'd have to be associated to the "disk" group to read those
> >>things and you'd have to *be* root to write.
> >
> >*THAT* sentence may be key to solving multiple problems. All of
> >my installs have implicitly accepted default groups for user(s).
> 
> Evidently not a solution. Added myself to both "disk" and "root"
> groups.

Two things:
 - check that your disk devices are actually readable (and probably
   writable, I botched that, cf. David's mail) by group disk
 - your being added to disk is effective *after* logging in after
   you'd made the change; if you want to bypass it, there is the
   command 'newgrp'; you can check which groups you are "in" by
   issuing the command 'groups': 'disk' should be in there.

> Had no effect when attempting to run either lsblk or parted.

How does "no effect" look like?

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

iEYEARECAAYFAlggj0AACgkQBcgs9XrR2kbk/QCaAkM8EhnABt49GQ1g4Kwj7Lbg
4NgAniIeHOs+yyk2L5G8Au3Le+prZM7J
=pUD3
-----END PGP SIGNATURE-----

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

#174304

On Mon, Nov 07, 2016 at 03:27:12PM +0100, tomas@tuxteam.de wrote:
> Two things:
>  - check that your disk devices are actually readable (and probably
>    writable, I botched that, cf. David's mail) by group disk
>  - your being added to disk is effective *after* logging in after
>    you'd made the change; if you want to bypass it, there is the
>    command 'newgrp'; you can check which groups you are "in" by
>    issuing the command 'groups': 'disk' should be in there.

I started writing that in my previous message, but then I actually
tested it on my own system.  Good thing I did, because I got the
same result as Richard: being in group disk, which has read/write
access on /dev/sda*, does NOT give you output in the FSTYPE and other
fields of lsblk -f.  It certainly surprised me.

$ sudo adduser wooledg disk
Adding user `wooledg' to group `disk' ...
Adding user wooledg to group disk
Done.

$ su - wooledg -c 'LANG=C; id; lsblk -f'
Password: 
uid=563(wooledg) gid=563(wooledg) groups=563(wooledg),6(disk),24(cdrom),25(floppy),27(sudo),29(audio),30(dip),44(video),46(plugdev),108(netdev)
NAME   FSTYPE LABEL UUID MOUNTPOINT
sda                      
|-sda1                   
|-sda2                   /
`-sda3                   [SWAP]
sr0                      

Whatever lsblk wants in order to read the FSTYPE, I don't know, but
group disk membership is not sufficient.  (On jessie.)

I still suggest just sucking it up and using sudo like a normal person.

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

#174306

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

On Mon, Nov 07, 2016 at 09:35:32AM -0500, Greg Wooledge wrote:
> On Mon, Nov 07, 2016 at 03:27:12PM +0100, tomas@tuxteam.de wrote:
> > Two things:

[...]

> I started writing that in my previous message, but then I actually
> tested it on my own system.  Good thing I did, because I got the
> same result as Richard: being in group disk, which has read/write
> access on /dev/sda*, does NOT give you output in the FSTYPE and other
> fields of lsblk -f.  It certainly surprised me.

Indeed. I suspect lsblk is checking the user ID itself instead of
letting the OS do its thing. For whatever reasons I can't fathom.

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

iEYEARECAAYFAlggmC0ACgkQBcgs9XrR2kaXdgCfTQQDo3j7HF2GlTi5G9oxUhF2
BxsAnA2NxwiZjyEPDAREUeObLuVnwa7l
=MReN
-----END PGP SIGNATURE-----

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

#174317

	Hi.

On Mon, Nov 07, 2016 at 04:05:17PM +0100, tomas@tuxteam.de wrote:
> On Mon, Nov 07, 2016 at 09:35:32AM -0500, Greg Wooledge wrote:
> > I started writing that in my previous message, but then I actually
> > tested it on my own system.  Good thing I did, because I got the
> > same result as Richard: being in group disk, which has read/write
> > access on /dev/sda*, does NOT give you output in the FSTYPE and other
> > fields of lsblk -f.  It certainly surprised me.
> 
> Indeed. I suspect lsblk is checking the user ID itself instead of
> letting the OS do its thing. For whatever reasons I can't fathom.

According to the source (util-linux-2.25.2), '-f' flag should add these
to the output:

add_column(columns, ncolumns++, COL_NAME);
add_column(columns, ncolumns++, COL_FSTYPE);
add_column(columns, ncolumns++, COL_LABEL);
add_column(columns, ncolumns++, COL_UUID);
add_column(columns, ncolumns++, COL_TARGET);


To determine COL_FSTYPE, probe_device function is used.
The definition of this function contains this little gem (getuid call):

static void probe_device(struct blkdev_cxt *cxt)
{
...

    /* try udev DB */
    if (get_udev_properties(cxt) == 0)
        return;             /* success */

    cxt->probed = 1;

    /* try libblkid (fallback) */
    if (getuid() != 0)
        return;             /* no permissions to read from the device */

    pr = blkid_new_probe_from_filename(cxt->filename);
    if (!pr)
        return;

So whoever wrote this was either lazy or too smart or both, as
blkid_new_probe_from_filename does this:

blkid_probe blkid_new_probe_from_filename(const char *filename)
{
...

    fd = open(filename, O_RDONLY|O_CLOEXEC);
    if (fd < 0)
        return NULL;

I.e. insufficient device permissions will return NULL anyway, so there's
little point of checking whenever the calling user is root or not.

Reco

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

#174336

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

On Mon, Nov 07, 2016 at 07:54:23PM +0300, Reco wrote:
> 	Hi.
> 
> On Mon, Nov 07, 2016 at 04:05:17PM +0100, tomas@tuxteam.de wrote:
> > On Mon, Nov 07, 2016 at 09:35:32AM -0500, Greg Wooledge wrote:
> > > I started writing that in my previous message, but then I actually
> > > tested it on my own system.  Good thing I did, because I got the
> > > same result as Richard: being in group disk, which has read/write
> > > access on /dev/sda*, does NOT give you output in the FSTYPE and other
> > > fields of lsblk -f.  It certainly surprised me.
> > 
> > Indeed. I suspect lsblk is checking the user ID itself instead of
> > letting the OS do its thing. For whatever reasons I can't fathom.

[...]

> The definition of this function contains this little gem (getuid call):

[...]

>     /* try libblkid (fallback) */
>     if (getuid() != 0)
>         return;             /* no permissions to read from the device */

[...]

> I.e. insufficient device permissions will return NULL anyway, so there's
> little point of checking whenever the calling user is root or not.

Hey, thanks for actually following through. My dirty imagination was
right, for one time :-)

Actually this is an anti-pattern: trying to do a job in advance before
the "right" architecture layer has a chance at doing a better job.
More complexity, less functionality.

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

iEYEARECAAYFAlghmDQACgkQBcgs9XrR2kaAoACfTYpAbwbTnMVeqP6Dldyyo/M1
96sAn1VIzOsjtUpCFhQzuG/rvO2Ja/yA
=LN4U
-----END PGP SIGNATURE-----

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

#174326

Le 07/11/2016 à 15:18, Richard Owlett a écrit :
>>>
>>>    tomas@rasputin:~$ ls -al /dev/sd*
>>>    brw-rw---- 1 root disk 8, 0 Nov  7 09:06 /dev/sda
>>>    brw-rw---- 1 root disk 8, 1 Nov  7 09:06 /dev/sda1
>>>    brw-rw---- 1 root disk 8, 2 Nov  7 09:06 /dev/sda2
>>>    brw-rw---- 1 root disk 8, 5 Nov  7 09:06 /dev/sda5
>>>
>>> So you'd have to be associated to the "disk" group to read those
>>> things and you'd have to *be* root to write.
>
> Evidently not a solution. Added myself to both "disk" and "root" groups.
> Had no effect when attempting to run either lsblk or parted.

Did you start a new session after adding yourself to the group ?
New groups are only taken into account when opening a session.
FWIW, adding myself to the "disk" group and starting a new session 
worked with lsblk -f. Didn't try parted.

> Off-list it was suggested I try /sbin/blkid /dev/sda. Although the man
> page has a caution when not used as root, it seems to currently work on
> my immediately available Debian machine.

Indeed blkid uses a cache file which is readable by everyone and is 
updated by udev.

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

#174330

On Mon 07 Nov 2016 at 21:07:45 +0100, Pascal Hambourg wrote:

> Le 07/11/2016 à 15:18, Richard Owlett a écrit :
> >>>
> >>>   tomas@rasputin:~$ ls -al /dev/sd*
> >>>   brw-rw---- 1 root disk 8, 0 Nov  7 09:06 /dev/sda
> >>>   brw-rw---- 1 root disk 8, 1 Nov  7 09:06 /dev/sda1
> >>>   brw-rw---- 1 root disk 8, 2 Nov  7 09:06 /dev/sda2
> >>>   brw-rw---- 1 root disk 8, 5 Nov  7 09:06 /dev/sda5
> >>>
> >>>So you'd have to be associated to the "disk" group to read those
> >>>things and you'd have to *be* root to write.
> >
> >Evidently not a solution. Added myself to both "disk" and "root" groups.
> >Had no effect when attempting to run either lsblk or parted.
> 
> Did you start a new session after adding yourself to the group ?
> New groups are only taken into account when opening a session.
> FWIW, adding myself to the "disk" group and starting a new session worked
> with lsblk -f. Didn't try parted.

Is the suggestion to give a user raw access to disks a serious one?

> >Off-list it was suggested I try /sbin/blkid /dev/sda. Although the man
> >page has a caution when not used as root, it seems to currently work on
> >my immediately available Debian machine.
> 
> Indeed blkid uses a cache file which is readable by everyone and is updated
> by udev.

A very useful observation. When blkid is run as root it creates the file
/run/blkid/blkid.tab. A user running blkid only gets to see the contents
of blkid.tab. There is no change to blkid.tab unless the command is run
by root again. This makes /sbin/blkid useless as a user command for the
purposes discussed in this thread.

-- 
Brian. 

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

#174342

On 11/7/2016 5:54 PM, Brian wrote:
> On Mon 07 Nov 2016 at 21:07:45 +0100, Pascal Hambourg wrote:
>
>> Le 07/11/2016 à 15:18, Richard Owlett a écrit :
>>>>>
>>>>>    tomas@rasputin:~$ ls -al /dev/sd*
>>>>>    brw-rw---- 1 root disk 8, 0 Nov  7 09:06 /dev/sda
>>>>>    brw-rw---- 1 root disk 8, 1 Nov  7 09:06 /dev/sda1
>>>>>    brw-rw---- 1 root disk 8, 2 Nov  7 09:06 /dev/sda2
>>>>>    brw-rw---- 1 root disk 8, 5 Nov  7 09:06 /dev/sda5
>>>>>
>>>>> So you'd have to be associated to the "disk" group to read those
>>>>> things and you'd have to *be* root to write.
>>>
>>> Evidently not a solution. Added myself to both "disk" and "root" groups.
>>> Had no effect when attempting to run either lsblk or parted.
>>
>> Did you start a new session after adding yourself to the group ?
>> New groups are only taken into account when opening a session.
>> FWIW, adding myself to the "disk" group and starting a new session worked
>> with lsblk -f. Didn't try parted.
>
> Is the suggestion to give a user raw access to disks a serious one?
>
>>> Off-list it was suggested I try /sbin/blkid /dev/sda. Although the man
>>> page has a caution when not used as root, it seems to currently work on
>>> my immediately available Debian machine.
>>
>> Indeed blkid uses a cache file which is readable by everyone and is updated
>> by udev.
>
> A very useful observation. When blkid is run as root it creates the file
> /run/blkid/blkid.tab. A user running blkid only gets to see the contents
> of blkid.tab. There is no change to blkid.tab unless the command is run
> by root again. This makes /sbin/blkid useless as a user command for the
> purposes discussed in this thread.
>

I can confirm that on a fresh install /sbin/blkid does NOT return 
the desired information. However I do not recall running it as 
root before running it as user on the machine I had been using, 
so the may be other programs which create blkid.tab .

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

#174494

Le 08/11/2016 à 00:54, Brian a écrit :
>
> When blkid is run as root it creates the file
> /run/blkid/blkid.tab. A user running blkid only gets to see the contents
> of blkid.tab.

That does not appear to be completely correct.
If I run blkid as a standard user after plugging a USB drive, it lists 
the USB drive partition, although blikd.tab was not modified.

$ /sbin/blkid | grep sdb
/dev/sdb1: LABEL="USB DISK" UUID="48DB-E077" TYPE="vfat"

$ grep sdb /etc/blkid.tab || echo not found
not found

However note that /dev/sdb* is owned by group "floppy" and my standard 
user account is a member of this group.

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

#174496

On Fri 11 Nov 2016 at 15:38:07 +0100, Pascal Hambourg wrote:

> Le 08/11/2016 à 00:54, Brian a écrit :
> >
> >When blkid is run as root it creates the file
> >/run/blkid/blkid.tab. A user running blkid only gets to see the contents
> >of blkid.tab.
> 
> That does not appear to be completely correct.
> If I run blkid as a standard user after plugging a USB drive, it lists the
> USB drive partition, although blikd.tab was not modified.
> 
> $ /sbin/blkid | grep sdb
> /dev/sdb1: LABEL="USB DISK" UUID="48DB-E077" TYPE="vfat"
> 
> $ grep sdb /etc/blkid.tab || echo not found
> not found

As the manual says:

 CACHE_FILE=<path>
   Overrides the standard location of the cache file. This setting
   can be overridden by the environment variable BLKID_FILE. Default
   is /run/blkid/blkid.tab, or /etc/blkid.tab on systems without a
   /run directory.
 
> However note that /dev/sdb* is owned by group "floppy" and my standard user
> account is a member of this group.

If you are on Jessie (and have not altered any udev rules) you have a
broken system. Please post the output of 'ls -l /etc/udev/rules.d'.

-- 
Brian.

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

#174499

Le 11/11/2016 à 17:24, Brian a écrit :
>
> As the manual says:
>
>  CACHE_FILE=<path>
>    Overrides the standard location of the cache file. This setting
>    can be overridden by the environment variable BLKID_FILE. Default
>    is /run/blkid/blkid.tab, or /etc/blkid.tab on systems without a
>    /run directory.

In Wheezy the man page does not mention /run, and there is no 
/run/blkid/blkid.tab.

>> However note that /dev/sdb* is owned by group "floppy" and my standard user
>> account is a member of this group.
>
> If you are on Jessie (and have not altered any udev rules) you have a
> broken system.

This computer runs Wheezy and I did not alter udev rules. Looks like 
things have changed with Jessie.

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

#174501

On Fri 11 Nov 2016 at 18:09:33 +0100, Pascal Hambourg wrote:

> Le 11/11/2016 à 17:24, Brian a écrit :
> >
> >As the manual says:
> >
> > CACHE_FILE=<path>
> >   Overrides the standard location of the cache file. This setting
> >   can be overridden by the environment variable BLKID_FILE. Default
> >   is /run/blkid/blkid.tab, or /etc/blkid.tab on systems without a
> >   /run directory.
> 
> In Wheezy the man page does not mention /run, and there is no
> /run/blkid/blkid.tab.
> 
> >>However note that /dev/sdb* is owned by group "floppy" and my standard user
> >>account is a member of this group.
> >
> >If you are on Jessie (and have not altered any udev rules) you have a
> >broken system.
> 
> This computer runs Wheezy and I did not alter udev rules. Looks like things
> have changed with Jessie.

Wheezy has /etc/udev/rules.d/91-permissions.rules; Jessie doesn't.

This thread has a short discussion on gparted and bug #439409. The bug
report was submitted for Wheezy and the behaviour you observe formed
the basis of an argument. The bug report now has a different complexion
but has still not been updated to reflect the altered situation.

-- 
Brian.

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

#174295

On Mon 07 Nov 2016 at 13:47:27 (+0100), tomas@tuxteam.de wrote:
> On Mon, Nov 07, 2016 at 06:11:50AM -0600, Richard Owlett wrote:
> > I need to identify file system on all partitions of my hard drive
> > whether mounted or not.
> >     parted /dev/sda print | grep ext | grep -v exte
> > reports the desired information [partitions formatted ext?] in a
> > convenient format.
> > *HOWEVER* parted requires root privileges. That is not acceptable.
> > Suggestions?
> 
> It's not parted. It's the partitions themselves (or more accurately,
> the devices via which your operating system makes the partitions
> available to user space). By default (and there are some reasons
> for it) they're not readable by everyone. They are writable by
> even less. On my box, for example:
> 
>   tomas@rasputin:~$ ls -al /dev/sd*
>   brw-rw---- 1 root disk 8, 0 Nov  7 09:06 /dev/sda
>   brw-rw---- 1 root disk 8, 1 Nov  7 09:06 /dev/sda1
>   brw-rw---- 1 root disk 8, 2 Nov  7 09:06 /dev/sda2
>   brw-rw---- 1 root disk 8, 5 Nov  7 09:06 /dev/sda5
> 
> So you'd have to be associated to the "disk" group to read those
> things and you'd have to *be* root to write.

Are you sure? I read that as group disk having read *and* write access.

Obviously the OP seems unworried about read-access by himself or
anyone else, so world-readable on pretty much everything might
be appropriate.

Reading anything about a filesystem without going through the
normal access methods would appear to circumvent any file
protection scheme within it, so it's no surprise to me that
all the suggestions with lsblk etc have failed.

Cheers,
David.

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

#174296

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

On Mon, Nov 07, 2016 at 08:02:30AM -0600, David Wright wrote:
> On Mon 07 Nov 2016 at 13:47:27 (+0100), tomas@tuxteam.de wrote:
> > On Mon, Nov 07, 2016 at 06:11:50AM -0600, Richard Owlett wrote:
> > > I need to identify file system on all partitions of my hard drive
> > > whether mounted or not.
> > >     parted /dev/sda print | grep ext | grep -v exte
> > > reports the desired information [partitions formatted ext?] in a
> > > convenient format.
> > > *HOWEVER* parted requires root privileges. That is not acceptable.
> > > Suggestions?
> > 
> > It's not parted. It's the partitions themselves (or more accurately,
> > the devices via which your operating system makes the partitions
> > available to user space). By default (and there are some reasons
> > for it) they're not readable by everyone. They are writable by
> > even less. On my box, for example:
> > 
> >   tomas@rasputin:~$ ls -al /dev/sd*
> >   brw-rw---- 1 root disk 8, 0 Nov  7 09:06 /dev/sda
> >   brw-rw---- 1 root disk 8, 1 Nov  7 09:06 /dev/sda1
> >   brw-rw---- 1 root disk 8, 2 Nov  7 09:06 /dev/sda2
> >   brw-rw---- 1 root disk 8, 5 Nov  7 09:06 /dev/sda5
> > 
> > So you'd have to be associated to the "disk" group to read those
> > things and you'd have to *be* root to write.
> 
> Are you sure? I read that as group disk having read *and* write access.

Uh -- yes, you are right, of course.

> Obviously the OP seems unworried about read-access by himself or
> anyone else, so world-readable on pretty much everything might
> be appropriate.
> 
> Reading anything about a filesystem without going through the
> normal access methods would appear to circumvent any file
> protection scheme within it, so it's no surprise to me that
> all the suggestions with lsblk etc have failed.

Exactly.

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

iEYEARECAAYFAlggif0ACgkQBcgs9XrR2kbJcgCdHYCJJion+5jcdZuULe0HQ/B6
myIAn099gufCMVEbXGrP7ko0ffX9OM8/
=I0Ki
-----END PGP SIGNATURE-----

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

#174292

On Monday, November 07, 2016 07:11:50 AM Richard Owlett wrote:
> I need to identify file system on all partitions of my hard drive
> whether mounted or not.
>      parted /dev/sda print | grep ext | grep -v exte
> reports the desired information [partitions formatted ext?] in a
> convenient format.
> *HOWEVER* parted requires root privileges. That is not acceptable.
> Suggestions?
> TIA

This is probably irrelevant because parted doesn't seem to meet your needs 
anyway, but your parted command does not find encrypted partitions on my disk.  
(That could be bad or good ;-)  (It also did not find an unmounted partition 
containing no filesystem, but that may be the behavior you desire.)

[toc] | [prev] | [standalone]

Page 4 of 4 — ← Prev page 1 2 3 [4]

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

csiph-web