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

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

Problem attempting to use xorriso

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

Contents

  Problem attempting to use xorriso Richard Owlett <rowlett@cloud85.net> - 2016-11-04 20:30 +0100
    Re: Problem attempting to use xorriso "Thomas Schmitt" <scdbackup@gmx.net> - 2016-11-04 21:10 +0100
      Re: Problem attempting to use xorriso Richard Owlett <rowlett@cloud85.net> - 2016-11-06 17:50 +0100
        Re: Problem attempting to use xorriso "Thomas Schmitt" <scdbackup@gmx.net> - 2016-11-06 19:10 +0100
        Re: Problem attempting to use xorriso Lisi Reisz <lisi.reisz@gmail.com> - 2016-11-10 00:20 +0100
          Re: Problem attempting to use xorriso Richard Owlett <rowlett@cloud85.net> - 2016-11-10 12:00 +0100
            Re: Problem attempting to use xorriso <tomas@tuxteam.de> - 2016-11-10 12:30 +0100
              Re: Problem attempting to use xorriso Richard Owlett <rowlett@cloud85.net> - 2016-11-10 14:50 +0100
                Re: Problem attempting to use xorriso <tomas@tuxteam.de> - 2016-11-10 15:00 +0100
                  Re: Problem attempting to use xorriso Richard Owlett <rowlett@cloud85.net> - 2016-11-10 15:30 +0100
                    Re: Problem attempting to use xorriso <tomas@tuxteam.de> - 2016-11-10 15:50 +0100
            Re: Problem attempting to use xorriso Lisi Reisz <lisi.reisz@gmail.com> - 2016-11-10 16:00 +0100
              Re: Problem attempting to use xorriso <tomas@tuxteam.de> - 2016-11-10 16:20 +0100
              Re: Problem attempting to use xorriso Greg Wooledge <wooledg@eeg.ccf.org> - 2016-11-10 16:50 +0100
                Re: Problem attempting to use xorriso Lisi Reisz <lisi.reisz@gmail.com> - 2016-11-10 18:00 +0100
                Re: Problem attempting to use xorriso Richard Owlett <rowlett@cloud85.net> - 2016-11-11 00:10 +0100
              Re: Problem attempting to use xorriso Richard Owlett <rowlett@cloud85.net> - 2016-11-11 00:00 +0100
                Re: Problem attempting to use xorriso Lisi Reisz <lisi.reisz@gmail.com> - 2016-11-11 03:20 +0100
                Re: Problem attempting to use xorriso Curt <curty@free.fr> - 2016-11-11 11:10 +0100
                  Re: Problem attempting to use xorriso Lisi Reisz <lisi.reisz@gmail.com> - 2016-11-11 12:50 +0100
                  Re: Problem attempting to use xorriso Gene Heskett <gheskett@shentel.net> - 2016-11-11 19:20 +0100
                    Re: Problem attempting to use xorriso Curt <curty@free.fr> - 2016-11-12 11:20 +0100
                      Re: Problem attempting to use xorriso "Thomas Schmitt" <scdbackup@gmx.net> - 2016-11-12 12:00 +0100
                        Re: Problem attempting to use xorriso Gene Heskett <gheskett@shentel.net> - 2016-11-12 12:20 +0100
                        Re: Problem attempting to use xorriso Lisi Reisz <lisi.reisz@gmail.com> - 2016-11-12 14:30 +0100
            Re: Problem attempting to use xorriso David Wright <deblis@lionunicorn.co.uk> - 2016-11-10 21:00 +0100
              Re: Problem attempting to use xorriso Richard Owlett <rowlett@cloud85.net> - 2016-11-11 00:10 +0100
                Re: Problem attempting to use xorriso David Wright <deblis@lionunicorn.co.uk> - 2016-11-11 05:00 +0100
                  Re: Problem attempting to use xorriso Richard Owlett <rowlett@cloud85.net> - 2016-11-11 09:10 +0100

Page 1 of 2  [1] 2  Next page →

#174178 — Problem attempting to use xorriso

Due to limited bandwidth I purchase complete sets of Debian 
install DVDs.
I had successfully created *.iso files for 12 of the 13 DVDs for 
version 8.6.
[The MD5SUM of one DVD does not match list at 
http://cdimage.debian.org/debian-cd/8.6.0/i386/iso-dvd/MD5SUMS]

I attempted to follow the example given by Thomas Schmitt in 
https://lists.debian.org/debian-user/2015/09/msg00421.html He had 
suggested:

   for i in /media/distributionA/DVD*.iso
   do
     xorriso -osirrox on:auto_chmod_on -overwrite nondir \
             -indev "$i" \
             -extract /pool /media/distributionA/poolA
   done

To account for my current directory structure I had modified it 
to bee:

   for i in /media/root/jessie-dvds/dvd8_*.iso
   do
     xorriso -osirrox on:auto_chmod_on -overwrite nondir \
             -indev "$i" \
             -extract /pool /media/myrepo/pool
   done

My running copy of Debian is on /dev/sda9 and had ~4GB of 10GB used.
When my run crashed it had no free space left.

A extract of what showed on the terminal is:

Extracted from ISO image: file '/pool'='/media/myrepo/pool'
xorriso 1.3.2 : RockRidge filesystem manipulator, libburnia project.

Copying of file objects from ISO image to disk filesystem is: Enabled
xorriso : NOTE : Loading ISO image tree from LBA 0
xorriso : UPDATE : 5199 nodes read in 1 seconds
Drive current: -indev '/media/root/jessie-dvds/dvd8_11.iso'
Media current: stdio file, overwriteable
Media status : is written , is appendable
Media summary: 1 session, 2288090 data blocks, 4469m data, 5577m free
Volume id    : 'Debian 8.6.0 i386 11'
xorriso : UPDATE : 35 files restored ( 47065k) in 1 seconds , 34.6xD
xorriso : UPDATE : 37 files restored ( 72465k) in 3 seconds , 11.8xD
.
.
*MASSIVE SNIP*
.
.
xorriso : UPDATE : 2991 files restored (2646.6m) in 336 seconds , 
0.9xD
xorriso : UPDATE : 3016 files restored (2648.1m) in 337 seconds , 
1.1xD
xorriso : FAILURE : Cannot write all bytes to disk filesystem 
path '/media/myrepo/pool/main/n/ns3/ns3-doc_3.17+dfsg-1_all.deb' 
: No space left on device
xorriso : FAILURE : Cannot restore regular file to disk 
filesystem: '/pool/main/n/ns3/ns3-doc_3.17+dfsg-1_all.deb'
xorriso : SORRY : Restoring failed: 
'/pool/main/n/ns3/ns3-doc_3.17+dfsg-1_all.deb' = 
'/media/myrepo/pool/main/n/ns3/ns3-doc_3.17+dfsg-1_all.deb'
xorriso : UPDATE : 3022 files restored (2649.4m) in 338 seconds = 
5.9xD
xorriso : aborting : -abort_on 'FAILURE' encountered 'FAILURE'
xorriso 1.3.2 : RockRidge filesystem manipulator, libburnia project.

Copying of file objects from ISO image to disk filesystem is: Enabled
xorriso : NOTE : Loading ISO image tree from LBA 0
xorriso : UPDATE : 4569 nodes read in 1 seconds
Drive current: -indev '/media/root/jessie-dvds/dvd8_12.iso'
Media current: stdio file, overwriteable
Media status : is written , is appendable
Media summary: 1 session, 2290589 data blocks, 4474m data, 5577m free
Volume id    : 'Debian 8.6.0 i386 12'
xorriso : FAILURE : Cannot restore directory to disk filesystem: 
'/pool/contrib/b/beast-mcmc' : No space left on device
xorriso : SORRY : Restoring failed:  '/pool/contrib/b/beast-mcmc' 
= '/media/myrepo/pool/contrib/b/beast-mcmc'
xorriso : aborting : -abort_on 'FAILURE' encountered 'FAILURE'
xorriso 1.3.2 : RockRidge filesystem manipulator, libburnia project.

*NOTHING* had gotten thru to intended destination partition.

How many things did I do wrong?
Help please.

[toc] | [next] | [standalone]

#174179

Hi,

Richard Owlett's xorriso wrote:
> xorriso : FAILURE : Cannot write all bytes to disk filesystem path '/media/myrepo/pool/main/n/ns3/ns3-doc_3.17+dfsg-1_all.deb' : No space left on device
> ...
> xorriso : aborting : -abort_on 'FAILURE' encountered 'FAILURE'

Looks like the filesystem to which you copy is full.


> My running copy of Debian is on /dev/sda9 and had ~4GB of 10GB used.

Determine the device file and mount point of the destination by

  df /media/myrepo/pool/main/n/ns3

or if missing by the lowest existing directory above that path.

It should tell you something like

  Filesystem     1K-blocks     Used Available Use% Mounted on
  /dev/sda3      490205312 23072576 442208680   5% /

but with "Use%" 99% or 100% and possible a mount path longer than "/".
That's where you would have to make room.


Have a nice day :)

Thomas

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

#174253

On 11/4/2016 3:04 PM, Thomas Schmitt wrote:
> Hi,
>
> Richard Owlett's xorriso wrote:
>> xorriso : FAILURE : Cannot write all bytes to disk filesystem path '/media/myrepo/pool/main/n/ns3/ns3-doc_3.17+dfsg-1_all.deb' : No space left on device
>> ...
>> xorriso : aborting : -abort_on 'FAILURE' encountered 'FAILURE'
>
> Looks like the filesystem to which you copy is full.
>
>
>> My running copy of Debian is on /dev/sda9 and had ~4GB of 10GB used.
>
> Determine the device file and mount point of the destination by
>
>    df /media/myrepo/pool/main/n/ns3
>
> or if missing by the lowest existing directory above that path.
>
> It should tell you something like
>
>    Filesystem     1K-blocks     Used Available Use% Mounted on
>    /dev/sda3      490205312 23072576 442208680   5% /
>
> but with "Use%" 99% or 100% and possible a mount path longer than "/".
> That's where you would have to make room.
>

Evidently xorriso does EXACTLY what told to do
*NOT* what operator _THOUGHT_ he had told it to do ;/ <*ROFL*>

When I had "crashed and burned" on my reported run of xorriso, 
one of my attempts to figure out what had happened triggered a 
graphical display of that I had no space left and gave me an 
option to forcibly delete directories which physically resided on 
/dev/sda9 - which I did. I then had an apparently operable system.

Before seeing your message I did a fresh install of Debian to 
/dev/sda9 which was expanded from 10GB to 80GB.

I then modified my script to run xorriso by adding a manual 
breakpoints for trouble shooting:

   for i in /media/root/jessie-dvds/dvd8_*.iso
   do
     xorriso -osirrox on:auto_chmod_on -overwrite nondir \
             -indev "$i" \
             -extract /pool /media/myrepo/pool

     echo ""
     echo "*********************"
     echo "Just processed " "$i"
     read -p "press Enter (Ctrl+C to exit)" dummyvar
   done

Each time the script paused I did
   df /media/myrepo/pool/main/n
in a different terminal window. I displayed messages of the form:
>
> Filesystem 1K-blocks Used Available Use% Mounted on
> /dev/sda3 490205312 23072576 442208680 5% /
>
Under "Filesystem" it reported /dev/sda9 rather than the expected 
/dev/sda11 .
Caja indicates my "filesystem" contains 60.1 GB of which 57.7 GB 
are in /media/myrepo.
Nothing seems to have gotten to /dev/sda11 which was my intended 
destination.

Based on responses to previous posts titled "Trivial script will 
NOT execute" and "Permissions for an entire PARTITION" I have 
multiple problems understanding Linux file systems generally.

My current homework is to now re-read ~40 posts and a to be 
determined number of referenced links. Keywords will likely 
include path, working directory, inode and mount ;/

--
If retirement isn't for learning, what use is it.

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

#174254

Hi,

Richard Owlett wrote:
> Evidently xorriso does EXACTLY what told to do
> *NOT* what operator _THOUGHT_ he had told it to do ;/ <*ROFL*>

That's the curse of being a king with absolutely loyal subjetcs.


> a graphical display of
> that I had no space left and gave me an option to forcibly delete
> directories which physically resided on /dev/sda9

Scary. One should well consider before accepting such an offer.


> Under "Filesystem" it reported /dev/sda9 rather than the expected /dev/sda11
.
> [...]
> Nothing seems to have gotten to /dev/sda11 which was my intended destination.

Normally i think of filesystems by their mountpoint paths, not by
their partition device paths.
The command df shows a list which associates both path families.

Meanwhile we have lots of virtual filesystems like "tmpfs" or "udev".
One may keep them out of the list by a filter command which lets pass
only lines beginning by "/dev":

  df | grep '^/dev'

(Command "mount" without any arguments will list even more non-storage
 filesystems.)


> "Trivial script will NOT execute"

That one looks like you do not yet have in mind the meaning of shell
variable PATH when the shell has to execute a program path that does
not contain a "/" character.
Inspect content of PATH by

  echo " $PATH"

which should give a string of paths separated by colons ":". Like
   /home/thomas/bin:/usr/local/bin:/usr/bin:/bin
It is normally set by shell startup files, like /etc/profile, and
may be personalized by your file "$HOME"/.bashrc.

The shell tries the directories listed in PATH with commands of form

  command arguments

It looks only into the current working directory if the program path
begins by "./" (and has no other "/" in it):

  ./command arguments

If your command resides in some directory which is neither in PATH nor
the working directory, then you can run it by its complete file path:

  /home/thomas/command arguments


> "Permissions for an entire PARTITION"

That one became soon too brushy to follow, i fear.


Have a nice day :)

Thomas

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

#174447

On Sunday 06 November 2016 16:47:00 Richard Owlett wrote:
> On 11/4/2016 3:04 PM, Thomas Schmitt wrote:
> > Hi,
> >
> > Richard Owlett's xorriso wrote:
> >> xorriso : FAILURE : Cannot write all bytes to disk filesystem path
> >> '/media/myrepo/pool/main/n/ns3/ns3-doc_3.17+dfsg-1_all.deb' : No space
> >> left on device ...
> >> xorriso : aborting : -abort_on 'FAILURE' encountered 'FAILURE'
> >
> > Looks like the filesystem to which you copy is full.
> >
> >> My running copy of Debian is on /dev/sda9 and had ~4GB of 10GB used.
> >
> > Determine the device file and mount point of the destination by
> >
> >    df /media/myrepo/pool/main/n/ns3
> >
> > or if missing by the lowest existing directory above that path.
> >
> > It should tell you something like
> >
> >    Filesystem     1K-blocks     Used Available Use% Mounted on
> >    /dev/sda3      490205312 23072576 442208680   5% /
> >
> > but with "Use%" 99% or 100% and possible a mount path longer than "/".
> > That's where you would have to make room.
>
> Evidently xorriso does EXACTLY what told to do
> *NOT* what operator _THOUGHT_ he had told it to do ;/ <*ROFL*>
>
> When I had "crashed and burned" on my reported run of xorriso,
> one of my attempts to figure out what had happened triggered a
> graphical display of that I had no space left and gave me an
> option to forcibly delete directories which physically resided on
> /dev/sda9 - which I did. I then had an apparently operable system.
>
> Before seeing your message I did a fresh install of Debian to
> /dev/sda9 which was expanded from 10GB to 80GB.
>
> I then modified my script to run xorriso by adding a manual
> breakpoints for trouble shooting:
>
>    for i in /media/root/jessie-dvds/dvd8_*.iso
>    do
>      xorriso -osirrox on:auto_chmod_on -overwrite nondir \
>              -indev "$i" \
>              -extract /pool /media/myrepo/pool
>
>      echo ""
>      echo "*********************"
>      echo "Just processed " "$i"
>      read -p "press Enter (Ctrl+C to exit)" dummyvar
>    done
>
> Each time the script paused I did
>    df /media/myrepo/pool/main/n
>
> in a different terminal window. I displayed messages of the form:
> > Filesystem 1K-blocks Used Available Use% Mounted on
> > /dev/sda3 490205312 23072576 442208680 5% /
>
> Under "Filesystem" it reported /dev/sda9 rather than the expected
> /dev/sda11 .
> Caja indicates my "filesystem" contains 60.1 GB of which 57.7 GB
> are in /media/myrepo.
> Nothing seems to have gotten to /dev/sda11 which was my intended
> destination.
>
> Based on responses to previous posts titled "Trivial script will
> NOT execute" and "Permissions for an entire PARTITION" I have
> multiple problems understanding Linux file systems generally.

I imagine you have seen this lot - especially the top three??
https://www.google.co.uk/search?q=basic+debian+file+system&oq=basic+debian+file+system&aqs=chrome..69i57.7617j0j7&sourceid=chrome&ie=UTF-8

Lisi



>
> My current homework is to now re-read ~40 posts and a to be
> determined number of referenced links. Keywords will likely
> include path, working directory, inode and mount ;/
>
> --
> If retirement isn't for learning, what use is it.

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

#174456

On 11/9/2016 5:16 PM, Lisi Reisz wrote:
> On Sunday 06 November 2016 16:47:00 Richard Owlett wrote:
>> [snip]
>> Based on responses to previous posts titled "Trivial script will
>> NOT execute" and "Permissions for an entire PARTITION" I have
>> multiple problems understanding Linux file systems generally.
>
> I imagine you have seen this lot - especially the top three??
> https://www.google.co.uk/search?q=basic+debian+file+system&oq=basic+debian+file+system&aqs=chrome..69i57.7617j0j7&sourceid=chrome&ie=UTF-8
>
> Lisi

Yes, but not in the context of a sub-project from last few days.
I suspect what I aiming at might look like - the groups and 
permission bits set at time partition created, thus avoiding 
games with /etc/fstab .

richard@jessie-defaults:~$
richard@jessie-defaults:~$ ls -l /dev/sd*
brw-rw---- 1 root disk 8,  0 Nov 10 03:35 /dev/sda
brw-rw---- 1 root owl  8,  1 Nov 10 03:35 /dev/sda1
brw-rw-r-- 1 root owl  8,  2 Nov 10 03:35 /dev/sda2
brw-rw---- 1 root disk 8,  3 Nov 10 03:35 /dev/sda3
brw-rw---- 1 root disk 8,  5 Nov 10 03:35 /dev/sda5
brw-rw---- 1 root disk 8, 16 Nov 10 04:43 /dev/sdb
br--rw-r-- 1 root owl  8, 17 Nov 10 04:43 /dev/sdb1
richard@jessie-defaults:~$



>
>
>
>>
>> My current homework is to now re-read ~40 posts and a to be
>> determined number of referenced links. Keywords will likely
>> include path, working directory, inode and mount ;/
>>
>> --
>> If retirement isn't for learning, what use is it.
>
>

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

#174457

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

On Thu, Nov 10, 2016 at 04:53:47AM -0600, Richard Owlett wrote:
> On 11/9/2016 5:16 PM, Lisi Reisz wrote:
> >On Sunday 06 November 2016 16:47:00 Richard Owlett wrote:
> >>[snip]
> >>Based on responses to previous posts titled "Trivial script will
> >>NOT execute" and "Permissions for an entire PARTITION" I have
> >>multiple problems understanding Linux file systems generally.
> >
> >I imagine you have seen this lot - especially the top three??
> >https://www.google.co.uk/search?q=basic+debian+file+system&oq=basic+debian+file+system&aqs=chrome..69i57.7617j0j7&sourceid=chrome&ie=UTF-8
> >
> >Lisi
> 
> Yes, but not in the context of a sub-project from last few days.
> I suspect what I aiming at might look like - the groups and
> permission bits set at time partition created, thus avoiding games
> with /etc/fstab .
> 
> richard@jessie-defaults:~$
> richard@jessie-defaults:~$ ls -l /dev/sd*
> brw-rw---- 1 root disk 8,  0 Nov 10 03:35 /dev/sda
> brw-rw---- 1 root owl  8,  1 Nov 10 03:35 /dev/sda1
> brw-rw-r-- 1 root owl  8,  2 Nov 10 03:35 /dev/sda2
> brw-rw---- 1 root disk 8,  3 Nov 10 03:35 /dev/sda3
> brw-rw---- 1 root disk 8,  5 Nov 10 03:35 /dev/sda5
> brw-rw---- 1 root disk 8, 16 Nov 10 04:43 /dev/sdb
> br--rw-r-- 1 root owl  8, 17 Nov 10 04:43 /dev/sdb1

Note that with this setting, "you" can thrash whatever is in /dev/sda
through /dev/sdb (write access). Besides "everyone" can peek into
/dev/sda2 and /dev/sdb1.

And by "you" I'm talking about any program running on your behalf,
i.e. an executable attachment to this mail which your mail reader
might let through, or a LaTeX class c&p'ed off the Interwebs.

This is not to scare you: just to help you tune your awareness
towards such things.

> >>If retirement isn't for learning, what use is it.

:-)

regards

- -- tomás
   "I'm a signature virus. Go ahead and copy me into your signature"
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.12 (GNU/Linux)

iEUEARECAAYFAlgkV/4ACgkQBcgs9XrR2kZQSQCY+9nfiKPCIxbQ7Q2qedmSt1dS
NgCfYroYPuSLFKLe7SlsLN+vMBe1GH8=
=j2Ks
-----END PGP SIGNATURE-----

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

#174464

On 11/10/2016 5:20 AM, tomas@tuxteam.de wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On Thu, Nov 10, 2016 at 04:53:47AM -0600, Richard Owlett wrote:
>> On 11/9/2016 5:16 PM, Lisi Reisz wrote:
>>> On Sunday 06 November 2016 16:47:00 Richard Owlett wrote:
>>>> [snip]
>>>> Based on responses to previous posts titled "Trivial script will
>>>> NOT execute" and "Permissions for an entire PARTITION" I have
>>>> multiple problems understanding Linux file systems generally.
>>>
>>> I imagine you have seen this lot - especially the top three??
>>> https://www.google.co.uk/search?q=basic+debian+file+system&oq=basic+debian+file+system&aqs=chrome..69i57.7617j0j7&sourceid=chrome&ie=UTF-8
>>>
>>> Lisi
>>
>> Yes, but not in the context of a sub-project from last few days.
>> I suspect what I aiming at might look like - the groups and
>> permission bits set at time partition created, thus avoiding games
>> with /etc/fstab .
>>
>> richard@jessie-defaults:~$
>> richard@jessie-defaults:~$ ls -l /dev/sd*
>> brw-rw---- 1 root disk 8,  0 Nov 10 03:35 /dev/sda
>> brw-rw---- 1 root owl  8,  1 Nov 10 03:35 /dev/sda1
>> brw-rw-r-- 1 root owl  8,  2 Nov 10 03:35 /dev/sda2
>> brw-rw---- 1 root disk 8,  3 Nov 10 03:35 /dev/sda3
>> brw-rw---- 1 root disk 8,  5 Nov 10 03:35 /dev/sda5
>> brw-rw---- 1 root disk 8, 16 Nov 10 04:43 /dev/sdb
>> br--rw-r-- 1 root owl  8, 17 Nov 10 04:43 /dev/sdb1
>
> Note that with this setting, "you" can thrash whatever is in /dev/sda
> through /dev/sdb (write access).

I don't understand.

> Besides "everyone" can peek into /dev/sda2 and /dev/sdb1.

That was intentional ;)
The project I have in mind is a very custom repository. The set 
of files on sda2 would be almost final versions for use on my 
local machine. The files on the flash drive would be final 
release for use on someone else's machine.
>
> And by "you" I'm talking about any program running on your behalf,
> i.e. an executable attachment to this mail which your mail reader
> might let through, or a LaTeX class c&p'ed off the Interwebs.
>
> This is not to scare you: just to help you tune your awareness
> towards such things.

It doesn't "scare" me for a very good reason - the system in 
question has no network capability, let alone internet access. In 
fact the particular laptop had its disk wiped and a fresh install 
of Debian 3 times yesterday.

Also, as this is a publicly readable list, it is *EXTREMELY OK* 
to add warnings.,
I may be a raw newbie to Linux but have had much contact with 
"shoot self in foot" syndrome, both as subject and as rescuer ;/

Your response is encouraging, I am understanding more of how 
Debian reports information, even if I don't know how to put my 
system in the reported state.

Lets analyze the above *FICTITIOUS* system - "Am I interpreting 
each line correctly?"

I see no problem with the lines
    brw-rw---- 1 root disk 8,  0 Nov 10 03:35 /dev/sda
    brw-rw---- 1 root disk 8, 16 Nov 10 04:43 /dev/sdb
They are copied from a standard install. /dev/sda is my internal 
hard disk and /dev/sdb is a USB flash drive. They are owned by 
"root" and accessible by members of "disk".

These lines should be harmless
    brw-rw---- 1 root disk 8,  3 Nov 10 03:35 /dev/sda3
    brw-rw---- 1 root disk 8,  5 Nov 10 03:35 /dev/sda5
as they are also from defaults ( sda3 has Debian and sda5 is swap)

Now for my strange lines.

brw-rw---- 1 root proj2 8, 1 Nov 10 03:35 /dev/sda1
My previous use of "owl" as a group designation may have confused 
things.
On my system I am "richard" who is a member of group "richard".
"owl" was chosen as a group designation to avoid any accidental 
name collision.
In actual use there would likely be groups "proj1", "proj2", and 
"proj3" for separate projects. User "richard" would be a member 
of groups "richard" and "proj3" but not of "proj1" or "proj2".

I see no potential problem with this line. User "root" and 
members of "proj2" have read/write permissions. Execute 
permissions would be bogus as these partitions explicitly contain 
only data. No access for others.

As stated above sda2 is world readable as it contains a late 
pre-release copy of my custom repository.
brw-rw-r-- 1 root proj3 8, 2 Nov 10 03:35 /dev/sda2

Similarly for sdb1. Did not give "root" write permission as a 
precaution against accidental corruption as it is a removable 
drive which may be used anywhere. It is not intended to give 
protection from malicious changes.
br--rw-r-- 1 root proj3 8, 17 Nov 10 04:43 /dev/sdb1

These indicate desired results. How much effort required to 
obtain ?????

Thank you for your time.









>
>>>> If retirement isn't for learning, what use is it.
>
> :-)
>
> regards
>
> - -- tomás
>     "I'm a signature virus. Go ahead and copy me into your signature"
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.12 (GNU/Linux)
>
> iEUEARECAAYFAlgkV/4ACgkQBcgs9XrR2kZQSQCY+9nfiKPCIxbQ7Q2qedmSt1dS
> NgCfYroYPuSLFKLe7SlsLN+vMBe1GH8=
> =j2Ks
> -----END PGP SIGNATURE-----
>

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

#174465

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

On Thu, Nov 10, 2016 at 07:40:06AM -0600, Richard Owlett wrote:
> On 11/10/2016 5:20 AM, tomas@tuxteam.de wrote:
> >-----BEGIN PGP SIGNED MESSAGE-----
> >Hash: SHA1
> >
> >On Thu, Nov 10, 2016 at 04:53:47AM -0600, Richard Owlett wrote:
> >>On 11/9/2016 5:16 PM, Lisi Reisz wrote:
> >>>On Sunday 06 November 2016 16:47:00 Richard Owlett wrote:
> >>>>[snip]
> >>>>Based on responses to previous posts titled "Trivial script will
> >>>>NOT execute" and "Permissions for an entire PARTITION" I have
> >>>>multiple problems understanding Linux file systems generally.
> >>>
> >>>I imagine you have seen this lot - especially the top three??
> >>>https://www.google.co.uk/search?q=basic+debian+file+system&oq=basic+debian+file+system&aqs=chrome..69i57.7617j0j7&sourceid=chrome&ie=UTF-8
> >>>
> >>>Lisi
> >>
> >>Yes, but not in the context of a sub-project from last few days.
> >>I suspect what I aiming at might look like - the groups and
> >>permission bits set at time partition created, thus avoiding games
> >>with /etc/fstab .
> >>
> >>richard@jessie-defaults:~$
> >>richard@jessie-defaults:~$ ls -l /dev/sd*
> >>brw-rw---- 1 root disk 8,  0 Nov 10 03:35 /dev/sda
> >>brw-rw---- 1 root owl  8,  1 Nov 10 03:35 /dev/sda1
> >>brw-rw-r-- 1 root owl  8,  2 Nov 10 03:35 /dev/sda2
> >>brw-rw---- 1 root disk 8,  3 Nov 10 03:35 /dev/sda3
> >>brw-rw---- 1 root disk 8,  5 Nov 10 03:35 /dev/sda5
> >>brw-rw---- 1 root disk 8, 16 Nov 10 04:43 /dev/sdb
> >>br--rw-r-- 1 root owl  8, 17 Nov 10 04:43 /dev/sdb1
> >
> >Note that with this setting, "you" can thrash whatever is in /dev/sda
> >through /dev/sdb (write access).
> 
> I don't understand.

Hm. Too concise (both of us ;-)

I'll give it a shot. By "you" I meant "user owl, i.e. any program running
under that user". Was that the unclear part?

[...]

> It doesn't "scare" me for a very good reason - the system in
> question has no network capability, let alone internet access. In
> fact the particular laptop had its disk wiped and a fresh install of
> Debian 3 times yesterday.

I know. Just refining some points to keep in mind: not every "malware"
comes "directly" from the Internet. It may be through a malicious
USB stick; it may be that neat Emacs Lisp given to you, it may be
a PostScript file or a PDF, it may be (given suitable vulnerabilities)
a JPEG or a video.

But yeah, I'm all for "keep your eyes open, and whenever you miss
one of your feet, learn from it". I practice that myself :-)

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

iEYEARECAAYFAlgkfOsACgkQBcgs9XrR2kYChACeIqPJ6dJcz2JmCosiF4nnPAP4
YwYAnRLlgs0fs3EKdbMLxgelFviXRv4w
=S+f0
-----END PGP SIGNATURE-----

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

#174469

On 11/10/2016 7:58 AM, tomas@tuxteam.de wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On Thu, Nov 10, 2016 at 07:40:06AM -0600, Richard Owlett wrote:
>> On 11/10/2016 5:20 AM, tomas@tuxteam.de wrote:
>>> -----BEGIN PGP SIGNED MESSAGE-----
>>> Hash: SHA1
>>>
>>> On Thu, Nov 10, 2016 at 04:53:47AM -0600, Richard Owlett wrote:
>>>> On 11/9/2016 5:16 PM, Lisi Reisz wrote:
>>>>> On Sunday 06 November 2016 16:47:00 Richard Owlett wrote:
>>>>>> [snip]
>>>>>> Based on responses to previous posts titled "Trivial script will
>>>>>> NOT execute" and "Permissions for an entire PARTITION" I have
>>>>>> multiple problems understanding Linux file systems generally.
>>>>>
>>>>> I imagine you have seen this lot - especially the top three??
>>>>> https://www.google.co.uk/search?q=basic+debian+file+system&oq=basic+debian+file+system&aqs=chrome..69i57.7617j0j7&sourceid=chrome&ie=UTF-8
>>>>>
>>>>> Lisi
>>>>
>>>> Yes, but not in the context of a sub-project from last few days.
>>>> I suspect what I aiming at might look like - the groups and
>>>> permission bits set at time partition created, thus avoiding games
>>>> with /etc/fstab .
>>>>
>>>> richard@jessie-defaults:~$
>>>> richard@jessie-defaults:~$ ls -l /dev/sd*
>>>> brw-rw---- 1 root disk 8,  0 Nov 10 03:35 /dev/sda
>>>> brw-rw---- 1 root owl  8,  1 Nov 10 03:35 /dev/sda1
>>>> brw-rw-r-- 1 root owl  8,  2 Nov 10 03:35 /dev/sda2
>>>> brw-rw---- 1 root disk 8,  3 Nov 10 03:35 /dev/sda3
>>>> brw-rw---- 1 root disk 8,  5 Nov 10 03:35 /dev/sda5
>>>> brw-rw---- 1 root disk 8, 16 Nov 10 04:43 /dev/sdb
>>>> br--rw-r-- 1 root owl  8, 17 Nov 10 04:43 /dev/sdb1
>>>
>>> Note that with this setting, "you" can thrash whatever is in /dev/sda
>>> through /dev/sdb (write access).
>>
>> I don't understand.
>
> Hm. Too concise (both of us ;-)
>
> I'll give it a shot. By "you" I meant "user owl, i.e. any program running
> under that user". Was that the unclear part?

If not, it was likely related. "owl" was not intended to be a 
user ID, but a group ID.
That's why in my long winded response I changed "owl" to one of 
"proj1", "proj2", or "proj3" and clairified that I am user 
"richard" of group "richard".

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

#174473

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

On Thu, Nov 10, 2016 at 08:27:58AM -0600, Richard Owlett wrote:
> On 11/10/2016 7:58 AM, tomas@tuxteam.de wrote:

[...]

> >>I don't understand.
> >
> >Hm. Too concise (both of us ;-)
> >
> >I'll give it a shot. By "you" I meant "user owl, i.e. any program running
> >under that user". Was that the unclear part?
> 
> If not, it was likely related. "owl" was not intended to be a user
> ID, but a group ID.
> That's why in my long winded response I changed "owl" to one of
> "proj1", "proj2", or "proj3" and clairified that I am user "richard"
> of group "richard".

I think I got it. Thanks.

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

iEYEARECAAYFAlgkiEEACgkQBcgs9XrR2kaRwACeJqga5uC/HAUD5aBlEStGhxbC
PrUAnirvzib6abAcQEv1Cigy+QuJGI0Z
=Y/Bu
-----END PGP SIGNATURE-----

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

#174474

On Thursday 10 November 2016 10:53:47 Richard Owlett wrote:
> On 11/9/2016 5:16 PM, Lisi Reisz wrote:
> > On Sunday 06 November 2016 16:47:00 Richard Owlett wrote:
> >> [snip]
> >> Based on responses to previous posts titled "Trivial script will
> >> NOT execute" and "Permissions for an entire PARTITION" I have
> >> multiple problems understanding Linux file systems generally.
> >
> > I imagine you have seen this lot - especially the top three??
> > https://www.google.co.uk/search?q=basic+debian+file+system&oq=basic+debia
> >n+file+system&aqs=chrome..69i57.7617j0j7&sourceid=chrome&ie=UTF-8
> >
> > Lisi
>
> Yes, but not in the context of a sub-project from last few days.
> I suspect what I aiming at might look like - the groups and
> permission bits set at time partition created, thus avoiding
> games with /etc/fstab .
>
> richard@jessie-defaults:~$
> richard@jessie-defaults:~$ ls -l /dev/sd*
> brw-rw---- 1 root disk 8,  0 Nov 10 03:35 /dev/sda
> brw-rw---- 1 root owl  8,  1 Nov 10 03:35 /dev/sda1
> brw-rw-r-- 1 root owl  8,  2 Nov 10 03:35 /dev/sda2
> brw-rw---- 1 root disk 8,  3 Nov 10 03:35 /dev/sda3
> brw-rw---- 1 root disk 8,  5 Nov 10 03:35 /dev/sda5
> brw-rw---- 1 root disk 8, 16 Nov 10 04:43 /dev/sdb
> br--rw-r-- 1 root owl  8, 17 Nov 10 04:43 /dev/sdb1
> richard@jessie-defaults:~$
>
> >> My current homework is to now re-read ~40 posts and a to be
> >> determined number of referenced links. Keywords will likely
> >> include path, working directory, inode and mount ;/
> >>
> >> --
> >> If retirement isn't for learning, what use is it.

Richard - are you clear that the permissions are not for the partitions but 
for the directories on the mount points on the filing system on which those 
partitions have been hung??  This can be hard to grasp, but it can and does 
sometimes make a difference, e.g. if the same partition or device gets 
mounted somewhere else.

Being slightly older than you, Richard and coming from the pre-electronic 
computer generation, I am hoping to grasp and understand the basic Unix 
filing system finally some time before I keel over.  (I *think* that 
electronic computers are slightly older than you are.) ;-)

Lisi

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

#174475

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

On Thu, Nov 10, 2016 at 02:53:14PM +0000, Lisi Reisz wrote:
> On Thursday 10 November 2016 10:53:47 Richard Owlett wrote:
> > On 11/9/2016 5:16 PM, Lisi Reisz wrote:
> > > On Sunday 06 November 2016 16:47:00 Richard Owlett wrote:
> > >> [snip]
> > >> Based on responses to previous posts titled "Trivial script will
> > >> NOT execute" and "Permissions for an entire PARTITION" I have
> > >> multiple problems understanding Linux file systems generally.
> > >
> > > I imagine you have seen this lot - especially the top three??
> > > https://www.google.co.uk/search?q=basic+debian+file+system&oq=basic+debia
> > >n+file+system&aqs=chrome..69i57.7617j0j7&sourceid=chrome&ie=UTF-8
> > >
> > > Lisi
> >
> > Yes, but not in the context of a sub-project from last few days.
> > I suspect what I aiming at might look like - the groups and
> > permission bits set at time partition created, thus avoiding
> > games with /etc/fstab .
> >
> > richard@jessie-defaults:~$
> > richard@jessie-defaults:~$ ls -l /dev/sd*
> > brw-rw---- 1 root disk 8,  0 Nov 10 03:35 /dev/sda
> > brw-rw---- 1 root owl  8,  1 Nov 10 03:35 /dev/sda1
> > brw-rw-r-- 1 root owl  8,  2 Nov 10 03:35 /dev/sda2
> > brw-rw---- 1 root disk 8,  3 Nov 10 03:35 /dev/sda3
> > brw-rw---- 1 root disk 8,  5 Nov 10 03:35 /dev/sda5
> > brw-rw---- 1 root disk 8, 16 Nov 10 04:43 /dev/sdb
> > br--rw-r-- 1 root owl  8, 17 Nov 10 04:43 /dev/sdb1
> > richard@jessie-defaults:~$
> >
> > >> My current homework is to now re-read ~40 posts and a to be
> > >> determined number of referenced links. Keywords will likely
> > >> include path, working directory, inode and mount ;/
> > >>
> > >> --
> > >> If retirement isn't for learning, what use is it.
> 
> Richard - are you clear that the permissions are not for the partitions but 
> for the directories on the mount points on the filing system on which those 
> partitions have been hung??

Now I'm confused: what Richard shows up there are the permissions of the
*device files* in which (presumably, sometimes) some file system might
reside. Those file systems might (or might not) be mounted on some directory
in the file system tree (which we don't see here).

I think I didn't understand you.

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

iEYEARECAAYFAlgkjjkACgkQBcgs9XrR2kZc3QCdHwipsWGXye5IS2jXoIuaGfGO
nD0AniRApYYpR0N5yrPLIbrODNIUHbND
=U0+T
-----END PGP SIGNATURE-----

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

#174477

On Thu, Nov 10, 2016 at 02:53:14PM +0000, Lisi Reisz wrote:
> Richard - are you clear that the permissions are not for the partitions but 
> for the directories on the mount points on the filing system on which those 
> partitions have been hung??  This can be hard to grasp, but it can and does 
> sometimes make a difference, e.g. if the same partition or device gets 
> mounted somewhere else.
> 
> Being slightly older than you, Richard and coming from the pre-electronic 
> computer generation, I am hoping to grasp and understand the basic Unix 
> filing system finally some time before I keel over.  (I *think* that 
> electronic computers are slightly older than you are.) ;-)

Well, let's see if I can shed some light here.  Probably not, but
I'll try.

At the bottom layer of this whole thing, we've got actual hardware.
The computer can make the disk retrieve ("read") or store ("write")
information by modifying the voltage on various wires.  The kernel
knows how to tell the computer to do this (by dark magic).  The kernel
can, for example, read byte number 13543287 of the disk.

Storing all of your information in one gigantic chunk is not always
the best policy, so you have the ability to subdivide the disk into
"partitions".  Each partition is then treated as a separate hunk of
bytes.  The kernel also knows about these, and it can request byte
number 9986351 of partition number 3.

Even with partitions, retrieving information from a disk in this way
would be terribly inconvenient for most applications, so this is almost
never done.  Instead, there is another layer: the file system.  A disk,
or a partition, can have an organizational structure laid on top of
it which allows information to be stored in "files" which have names.
Instead of requesting byte number 9986351 of partition number 3, you can
request byte number 0 of the file named "bin/ls" inside the file system on
partition number 3.  This is the layer at which most applications operate.

Following the unix philosophy, the kernel presents an interface to each
of these layers, including access controls.

For the raw disk layer, there is a block device like /dev/sda.  You
can read byte number 13543287 of /dev/sda and see what it is.  In
order to do this, you need read permission on the /dev/sda file.

At the partition layer, there are block devices like /dev/sda3.  You
can read byte number 9986351 of /dev/sda3 and see what it is.  For
this, you need read permission on the /dev/sda3 file.

Those are simplistic layers, and not often used.  Pretty much the only
time you would ever read from one of those devices is to retrieve the
partition table from the disk, or to see what kind of file system is on
a given partition.  Lower level tools like mkfs and fsck and fdisk and
lsblk handle these details.

Things become much more interesting when we move up to the file system
layer.

The first thing to know about file systems is that they have to be
"mounted" in order to work.  The word "mount" comes from old tape drive
technology (reel to reel), when operators would be requested to mount
a tape, which is a physical act not dissimilar to hanging a picture on
a wall.  It has been adopted for file systems, even though there isn't
a physical movement of objects.

In order to mount a file system, you need to know which disk or partition
the file system is stored on, and what directory you want to attach it to.
You also have to be root, because this is a potentially VERY intrusive
thing to do.  If an ordinary user could mount a file system on /bin then
he could easily take over the whole system, because users would be
executing HIS version of /bin/ls and so on.

Typically the directory where you mount a file system is just an empty
stub.  But it doesn't have to be.  Let's say you have a single file
system (/) mounted currently, and it has a directory called "home" in
it.  Now let's say you've got some files in this directory.  If you mount
/dev/sda3 on /home then the contents of /dev/sda3's file system become
visible inside /home.  The files that you saw in /home BEFORE the mount
are hidden.  They're still in the / file system but you can't see them
or interact with them.

The second thing you need to know about file systems is that they
have their own metadata.  File ownerships, permissions, and so on are
stored within the inodes (index nodes) of the file system.  When you
mount the file system, you see only the files and the metadata from
the mounted file system.  The metadata of the directory that you mounted
it on is no longer relevant.  The metadata of the block device that
stores the file system is also irrelevant.

Before mounting:
drwxr-xr-x 4 john doe 4096 Aug 22 11:41 /home

After mounting:
drwxr-xr-x 4 root root 4096 Sep 22 11:41 /home

Block device:
brw-rw---- 1 root disk 8, 3 Nov  1 09:39 /dev/sda3

The group "disk" may have write access to /dev/sda3, but that doesn't
let them write to /home.  The permissions of /dev/sda3 are not relevant
when operating at the file system level.  On the other hand, a user
in group disk could write arbitrary bytes to the sda3 partition, which
would almost certainly CORRUPT the file system, because changes to the
underlying partition would be at war with changes made through the file
system layer.  You never, ever want to write to a device that is also
mounted as a file system (unless it's mounted read-only).

This is why you don't put ordinary users into the disk group.

The third thing you need to know about file systems is that, while you
do have to be root to mount them, there are tools that let ordinary
users TEMPORARILY have the root privileges needed to mount and unmount
file systems.  For example,

-rwsr-xr-x 1 root root 40000 Mar 29  2015 /bin/mount

The mount program is setuid root.  It has to be, in order for regular
users to be able to use it to mount file systems with temporary root
privileges.  Now obviously you don't want anyone to be able to mount
any file system on any directory.  That would be devastating.  So there
is an access control: the /etc/fstab file system defines what is allowed
to be mounted where, by ordinary users.  You do this by specifying the
"user" option on a file system entry.  The /etc/fstab file is only
writable by root, so ordinary users can't given themselves the ability
to mount stuff wherever they please.

As another example, Linux has a subsystem called "FUSE", which allows
users to mount some kinds of file systems on directories where they have
write permission.  sshfs is one example of this.  An ordinary user
can use the sshfs command to connect to a remote SFTP/SSH server in such
a way that the server's files become visible as a mounted file system
on the local machine.  Reads and writes are translated into SFTP commands.

And then there's autofs.  I... won't even try to cover autofs here.
This email is already long enough.

And then there's NFS, and iSCSI... same thing here.  Not gonna touch
those right now.

Of course, these are special exceptions.  On most systems, the set of
mounted file systems is defined during installation (possibly modified
when a new disk is added, or when a new partition is created).  These
file systems are defined in /etc/fstab, and they're all mounted when
the system boots.

If you want to share the file system on the /dev/sda13 partition across
multiple operating system installations, you simply add an entry in
/etc/fstab which says where you want to mount it at boot time, and presto!
It will be mounted there.  You do this in each operating system's own
/etc/fstab file so that each one of them mounts it when it boots.

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

#174481

Thanks, Greg!  That's brilliant! \o/

Lisi

On Thursday 10 November 2016 15:41:02 Greg Wooledge wrote:
> On Thu, Nov 10, 2016 at 02:53:14PM +0000, Lisi Reisz wrote:
> > Richard - are you clear that the permissions are not for the partitions
> > but for the directories on the mount points on the filing system on which
> > those partitions have been hung??  This can be hard to grasp, but it can
> > and does sometimes make a difference, e.g. if the same partition or
> > device gets mounted somewhere else.
> >
> > Being slightly older than you, Richard and coming from the pre-electronic
> > computer generation, I am hoping to grasp and understand the basic Unix
> > filing system finally some time before I keel over.  (I *think* that
> > electronic computers are slightly older than you are.) ;-)
>
> Well, let's see if I can shed some light here.  Probably not, but
> I'll try.
>
> At the bottom layer of this whole thing, we've got actual hardware.
> The computer can make the disk retrieve ("read") or store ("write")
> information by modifying the voltage on various wires.  The kernel
> knows how to tell the computer to do this (by dark magic).  The kernel
> can, for example, read byte number 13543287 of the disk.
>
> Storing all of your information in one gigantic chunk is not always
> the best policy, so you have the ability to subdivide the disk into
> "partitions".  Each partition is then treated as a separate hunk of
> bytes.  The kernel also knows about these, and it can request byte
> number 9986351 of partition number 3.
>
> Even with partitions, retrieving information from a disk in this way
> would be terribly inconvenient for most applications, so this is almost
> never done.  Instead, there is another layer: the file system.  A disk,
> or a partition, can have an organizational structure laid on top of
> it which allows information to be stored in "files" which have names.
> Instead of requesting byte number 9986351 of partition number 3, you can
> request byte number 0 of the file named "bin/ls" inside the file system on
> partition number 3.  This is the layer at which most applications operate.
>
> Following the unix philosophy, the kernel presents an interface to each
> of these layers, including access controls.
>
> For the raw disk layer, there is a block device like /dev/sda.  You
> can read byte number 13543287 of /dev/sda and see what it is.  In
> order to do this, you need read permission on the /dev/sda file.
>
> At the partition layer, there are block devices like /dev/sda3.  You
> can read byte number 9986351 of /dev/sda3 and see what it is.  For
> this, you need read permission on the /dev/sda3 file.
>
> Those are simplistic layers, and not often used.  Pretty much the only
> time you would ever read from one of those devices is to retrieve the
> partition table from the disk, or to see what kind of file system is on
> a given partition.  Lower level tools like mkfs and fsck and fdisk and
> lsblk handle these details.
>
> Things become much more interesting when we move up to the file system
> layer.
>
> The first thing to know about file systems is that they have to be
> "mounted" in order to work.  The word "mount" comes from old tape drive
> technology (reel to reel), when operators would be requested to mount
> a tape, which is a physical act not dissimilar to hanging a picture on
> a wall.  It has been adopted for file systems, even though there isn't
> a physical movement of objects.
>
> In order to mount a file system, you need to know which disk or partition
> the file system is stored on, and what directory you want to attach it to.
> You also have to be root, because this is a potentially VERY intrusive
> thing to do.  If an ordinary user could mount a file system on /bin then
> he could easily take over the whole system, because users would be
> executing HIS version of /bin/ls and so on.
>
> Typically the directory where you mount a file system is just an empty
> stub.  But it doesn't have to be.  Let's say you have a single file
> system (/) mounted currently, and it has a directory called "home" in
> it.  Now let's say you've got some files in this directory.  If you mount
> /dev/sda3 on /home then the contents of /dev/sda3's file system become
> visible inside /home.  The files that you saw in /home BEFORE the mount
> are hidden.  They're still in the / file system but you can't see them
> or interact with them.
>
> The second thing you need to know about file systems is that they
> have their own metadata.  File ownerships, permissions, and so on are
> stored within the inodes (index nodes) of the file system.  When you
> mount the file system, you see only the files and the metadata from
> the mounted file system.  The metadata of the directory that you mounted
> it on is no longer relevant.  The metadata of the block device that
> stores the file system is also irrelevant.
>
> Before mounting:
> drwxr-xr-x 4 john doe 4096 Aug 22 11:41 /home
>
> After mounting:
> drwxr-xr-x 4 root root 4096 Sep 22 11:41 /home
>
> Block device:
> brw-rw---- 1 root disk 8, 3 Nov  1 09:39 /dev/sda3
>
> The group "disk" may have write access to /dev/sda3, but that doesn't
> let them write to /home.  The permissions of /dev/sda3 are not relevant
> when operating at the file system level.  On the other hand, a user
> in group disk could write arbitrary bytes to the sda3 partition, which
> would almost certainly CORRUPT the file system, because changes to the
> underlying partition would be at war with changes made through the file
> system layer.  You never, ever want to write to a device that is also
> mounted as a file system (unless it's mounted read-only).
>
> This is why you don't put ordinary users into the disk group.
>
> The third thing you need to know about file systems is that, while you
> do have to be root to mount them, there are tools that let ordinary
> users TEMPORARILY have the root privileges needed to mount and unmount
> file systems.  For example,
>
> -rwsr-xr-x 1 root root 40000 Mar 29  2015 /bin/mount
>
> The mount program is setuid root.  It has to be, in order for regular
> users to be able to use it to mount file systems with temporary root
> privileges.  Now obviously you don't want anyone to be able to mount
> any file system on any directory.  That would be devastating.  So there
> is an access control: the /etc/fstab file system defines what is allowed
> to be mounted where, by ordinary users.  You do this by specifying the
> "user" option on a file system entry.  The /etc/fstab file is only
> writable by root, so ordinary users can't given themselves the ability
> to mount stuff wherever they please.
>
> As another example, Linux has a subsystem called "FUSE", which allows
> users to mount some kinds of file systems on directories where they have
> write permission.  sshfs is one example of this.  An ordinary user
> can use the sshfs command to connect to a remote SFTP/SSH server in such
> a way that the server's files become visible as a mounted file system
> on the local machine.  Reads and writes are translated into SFTP commands.
>
> And then there's autofs.  I... won't even try to cover autofs here.
> This email is already long enough.
>
> And then there's NFS, and iSCSI... same thing here.  Not gonna touch
> those right now.
>
> Of course, these are special exceptions.  On most systems, the set of
> mounted file systems is defined during installation (possibly modified
> when a new disk is added, or when a new partition is created).  These
> file systems are defined in /etc/fstab, and they're all mounted when
> the system boots.
>
> If you want to share the file system on the /dev/sda13 partition across
> multiple operating system installations, you simply add an entry in
> /etc/fstab which says where you want to mount it at boot time, and presto!
> It will be mounted there.  You do this in each operating system's own
> /etc/fstab file so that each one of them mounts it when it boots.

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

#174487

On 11/10/2016 9:41 AM, Greg Wooledge wrote:
>
> Well, let's see if I can shed some light here.  Probably not, but
> I'll try.
> [snip detailed essay]

Yes, you did shed needed light.
Thank you.

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

#174486

On 11/10/2016 8:53 AM, Lisi Reisz wrote:
> On Thursday 10 November 2016 10:53:47 Richard Owlett wrote:
>> On 11/9/2016 5:16 PM, Lisi Reisz wrote:
>>> On Sunday 06 November 2016 16:47:00 Richard Owlett wrote:
>>>> [snip]
>>>> Based on responses to previous posts titled "Trivial script will
>>>> NOT execute" and "Permissions for an entire PARTITION" I have
>>>> multiple problems understanding Linux file systems generally.
>>>
>>> I imagine you have seen this lot - especially the top three??
>>> https://www.google.co.uk/search?q=basic+debian+file+system&oq=basic+debia
>>> n+file+system&aqs=chrome..69i57.7617j0j7&sourceid=chrome&ie=UTF-8
>>>
>>> Lisi
>>
>> Yes, but not in the context of a sub-project from last few days.
>> I suspect what I aiming at might look like - the groups and
>> permission bits set at time partition created, thus avoiding
>> games with /etc/fstab .
>>
>> richard@jessie-defaults:~$
>> richard@jessie-defaults:~$ ls -l /dev/sd*
>> brw-rw---- 1 root disk 8,  0 Nov 10 03:35 /dev/sda
>> brw-rw---- 1 root owl  8,  1 Nov 10 03:35 /dev/sda1
>> brw-rw-r-- 1 root owl  8,  2 Nov 10 03:35 /dev/sda2
>> brw-rw---- 1 root disk 8,  3 Nov 10 03:35 /dev/sda3
>> brw-rw---- 1 root disk 8,  5 Nov 10 03:35 /dev/sda5
>> brw-rw---- 1 root disk 8, 16 Nov 10 04:43 /dev/sdb
>> br--rw-r-- 1 root owl  8, 17 Nov 10 04:43 /dev/sdb1
>> richard@jessie-defaults:~$
>>
>>>> My current homework is to now re-read ~40 posts and a to be
>>>> determined number of referenced links. Keywords will likely
>>>> include path, working directory, inode and mount ;/
>>>>
>>>> --
>>>> If retirement isn't for learning, what use is it.
>
> Richard - are you clear that the permissions are not for the partitions but
> for the directories on the mount points on the filing system on which those
> partitions have been hung??  This can be hard to grasp, but it can and does
> sometimes make a difference, e.g. if the same partition or device gets
> mounted somewhere else.

I'm getting the drift. It just one of things under the heading of 
"reality is a nuisance". There are a number of ways to tackle the 
problem that triggered my search. But they just ain't 
aesthetically pleasing.

>
> Being slightly older than you, Richard and coming from the pre-electronic
> computer generation, I am hoping to grasp and understand the basic Unix
> filing system finally some time before I keel over.  (I *think* that
> electronic computers are slightly older than you are.) ;-)

It may be close, I pre-date the Harvard MarkI. I am definitely 
older than Linus Torvalds father ;)
>
> Lisi
>
>

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

#174489

On Thursday 10 November 2016 22:56:41 Richard Owlett wrote:
> I pre-date the Harvard MarkI

But not, I think, Colossus.

Lisi

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

#174492

On 2016-11-10, Richard Owlett <rowlett@cloud85.net> wrote:
>
> It may be close, I pre-date the Harvard MarkI. I am definitely 
> older than Linus Torvalds father ;)
>>

Is this the senile equivalent of a pissing contest? Or the pissing
equivalent of a senile contest?

-- 
“It is enough that the arrows fit exactly in the wounds that they have made.”
Franz Kafka

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

#174493

On Friday 11 November 2016 10:07:42 Curt wrote:
> On 2016-11-10, Richard Owlett <rowlett@cloud85.net> wrote:
> > It may be close, I pre-date the Harvard MarkI. I am definitely
> > older than Linus Torvalds father ;)
>
> Is this the senile equivalent of a pissing contest? Or the pissing
> equivalent of a senile contest?

The pissing equivalent of a senile contest.

Lisi

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

Page 1 of 2  [1] 2  Next page →

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

csiph-web