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

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

Copying file has unexpected side effect

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

Contents

  Copying file has unexpected side effect Richard Owlett <rowlett@cloud85.net> - 2017-04-09 17:50 +0200
    Re: Copying file has unexpected side effect Richard Owlett <rowlett@cloud85.net> - 2017-04-09 18:10 +0200
      Re: Copying file has unexpected side effect Steve McIntyre <steve@einval.com> - 2017-04-09 21:50 +0200
        Re: Copying file has unexpected side effect Richard Owlett <rowlett@cloud85.net> - 2017-04-10 13:50 +0200
          Re: Copying file has unexpected side effect David Wright <deblis@lionunicorn.co.uk> - 2017-04-12 20:10 +0200

#179925 — Copying file has unexpected side effect

I have a laptop with multiple installs of Debian Jessie using MATE 
desktop. There are minor differences of package complements - the 
purpose being to determine an optimal configuration.

There are a relatively small number of files which I would like to have 
the latest version available no matter which install is active.

My solution was to place this files on a separate partition of the hdd.
It will be mounted at boot. The fstab entry is currently
UUID=E90C-65B4  /media/common vfat auto,exec,rw,flush,umask=000  0 0

The problem occurred on the very first use:
I opened /media/common by double-clicking its desktop icon.
I then:
   right-clicked on the desktop icon of a text file
   selected "Copy" from the menu
   moved mouse over the displayed directory of /media/common
   right-clicked and chose "Paste" from menu

The file was _apparently_ copied as expected.
*HOWEVER* the act of copying set the execution flag.
Why?

[toc] | [next] | [standalone]

#179927

On 04/09/2017 10:47 AM, Richard Owlett wrote:
> I have a laptop with multiple installs of Debian Jessie using MATE
> desktop. There are minor differences of package complements - the
> purpose being to determine an optimal configuration.
>
> There are a relatively small number of files which I would like to have
> the latest version available no matter which install is active.
>
> My solution was to place this files on a separate partition of the hdd.
> It will be mounted at boot. The fstab entry is currently
> UUID=E90C-65B4  /media/common vfat auto,exec,rw,flush,umask=000  0 0
>
> The problem occurred on the very first use:
> I opened /media/common by double-clicking its desktop icon.
> I then:
>   right-clicked on the desktop icon of a text file
>   selected "Copy" from the menu
>   moved mouse over the displayed directory of /media/common
>   right-clicked and chose "Paste" from menu
>
> The file was _apparently_ copied as expected.
> *HOWEVER* the act of copying set the execution flag.
> Why?

I received an almost OFFLIST reply stating:
"Because your fstab entry contains the exec directive for the whole
filesystem"

I suspected something of the sort. The man pages and wiki references 
were opaque on how to chose the various mask options.

What I had expected to happen was for execute flag to be whatever it had 
been set to on the source side.
I wanted all users to have rw permission - that was apparently accomplished.

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

#179936

rowlett@cloud85.net wrote:
>On 04/09/2017 10:47 AM, Richard Owlett wrote:
>>
>> My solution was to place this files on a separate partition of the hdd.
>> It will be mounted at boot. The fstab entry is currently
>> UUID=E90C-65B4  /media/common vfat auto,exec,rw,flush,umask=000  0 0
>>
>> The problem occurred on the very first use:
>> I opened /media/common by double-clicking its desktop icon.
>> I then:
>>   right-clicked on the desktop icon of a text file
>>   selected "Copy" from the menu
>>   moved mouse over the displayed directory of /media/common
>>   right-clicked and chose "Paste" from menu
>>
>> The file was _apparently_ copied as expected.
>> *HOWEVER* the act of copying set the execution flag.
>> Why?
>
>I received an almost OFFLIST reply stating:
>"Because your fstab entry contains the exec directive for the whole
>filesystem"
>
>I suspected something of the sort. The man pages and wiki references 
>were opaque on how to chose the various mask options.
>
>What I had expected to happen was for execute flag to be whatever it had 
>been set to on the source side.
>I wanted all users to have rw permission - that was apparently accomplished.

The bits are rwxrwxrwx. Setting them all maps to (octal) 777. The
umask determines which bits you *don't* want to see set from mount, so
umask=111 will strip the execute bits.

Alternatively, use a real filesystem that supports permissions
better (i.e. at all). vfat is horrid in many, many ways.

-- 
Steve McIntyre, Cambridge, UK.                                steve@einval.com
There's no sensation to compare with this
Suspended animation, A state of bliss

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

#179950

On 04/09/2017 02:40 PM, Steve McIntyre wrote:
> rowlett@cloud85.net wrote:
>> On 04/09/2017 10:47 AM, Richard Owlett wrote:

Re-inserting _*CRITICAL_ critical information from 1st post
<begin quote>
I have a laptop with multiple installs of Debian Jessie using MATE 
desktop. There are minor differences of package complements - the 
purpose being to determine an optimal configuration.

There are a relatively small number of files which I would like to have 
the latest version available no matter which install is active.
<end quote>


>>>
>>> My solution was to place this files on a separate partition of the >>> hdd. It will be mounted at boot. The fstab entry is currently
>>> UUID=E90C-65B4  /media/common vfat auto,exec,rw,flush,umask=000  0 0
>>>
>>> The problem occurred on the very first use:
>>> I opened /media/common by double-clicking its desktop icon.
>>> I then:
>>>   right-clicked on the desktop icon of a text file
>>>   selected "Copy" from the menu
>>>   moved mouse over the displayed directory of /media/common
>>>   right-clicked and chose "Paste" from menu
>>>
>>> The file was _apparently_ copied as expected.
>>> *HOWEVER* the act of copying set the execution flag.
>>> Why?
>>
>> I received an almost OFFLIST reply stating:
>> "Because your fstab entry contains the exec directive for the whole
>> filesystem"
>>
>> I suspected something of the sort. The man pages and wiki references
>> were opaque on how to chose the various mask options.
>>
>> What I had expected to happen was for execute flag to be whatever it >> had been set to on the source side.
>> I wanted all users to have rw permission - that was apparently
>> accomplished.
>
> The bits are rwxrwxrwx. Setting them all maps to (octal) 777. The
> umask determines which bits you *don't* want to see set from mount, so
> umask=111 will strip the execute bits.

That did not work as desired. The files on that partition can *NOT* be 
deleted.

The *EXPLICIT* purpose is for *EVERYONE* to absolutely free unfettered 
access to the files on that partition.
Think of it as a message board in the local grocery where anyone could 
post anything. Advertising flyers with tear off phone numbers included.

>
> Alternatively, use a real filesystem that supports permissions
> better (i.e. at all). vfat is horrid in many, many ways.
>

This machine doesn't have Windows on it. But I'll want to do the same 
thing on one with both Linux and Windows.

Ideas?

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

#180011

On Mon 10 Apr 2017 at 06:41:15 (-0500), Richard Owlett wrote:
> On 04/09/2017 02:40 PM, Steve McIntyre wrote:
> >rowlett@cloud85.net wrote:
> >>On 04/09/2017 10:47 AM, Richard Owlett wrote:
> 
> Re-inserting _*CRITICAL_ critical information from 1st post
> <begin quote>
> I have a laptop with multiple installs of Debian Jessie using MATE
> desktop. There are minor differences of package complements - the
> purpose being to determine an optimal configuration.
> 
> There are a relatively small number of files which I would like to
> have the latest version available no matter which install is active.
> <end quote>

The trouble is that that sounds like a repository of files that
could be readonly, whereas what later transpired is that you just
want a shared scratch area.

> >>>My solution was to place this files on a separate partition of the >>> hdd. It will be mounted at boot. The fstab entry is currently
> >>>UUID=E90C-65B4  /media/common vfat auto,exec,rw,flush,umask=000  0 0
> >>>
> >>>The problem occurred on the very first use:
> >>>I opened /media/common by double-clicking its desktop icon.
> >>>I then:
> >>>  right-clicked on the desktop icon of a text file
> >>>  selected "Copy" from the menu
> >>>  moved mouse over the displayed directory of /media/common
> >>>  right-clicked and chose "Paste" from menu
> >>>
> >>>The file was _apparently_ copied as expected.
> >>>*HOWEVER* the act of copying set the execution flag.
> >>>Why?

Because of the mask. But you don't say why this execute bit
is a problem, so is it, or could you just leave it?

> >>I received an almost OFFLIST reply stating:
> >>"Because your fstab entry contains the exec directive for the whole
> >>filesystem"
> >>
> >>I suspected something of the sort. The man pages and wiki references
> >>were opaque on how to chose the various mask options.

You're confusing two things. The exec mount option (redundant because
it's the default, though you might want to think of setting noexec
if you don't want these scratch files to be executed) has nothing
to do with the execute bits set by the mask. See   man mount.

> >>What I had expected to happen was for execute flag to be whatever it >> had been set to on the source side.
> >>I wanted all users to have rw permission - that was apparently
> >>accomplished.
> >
> >The bits are rwxrwxrwx. Setting them all maps to (octal) 777. The
> >umask determines which bits you *don't* want to see set from mount, so
> >umask=111 will strip the execute bits.
> 
> That did not work as desired. The files on that partition can *NOT*
> be deleted.

That won't be the only effect you'll observe when you strip the
execute bits from the directories as well as the files; they become
almost unusable. You need to set fmask and dmask separately, rather
than using umask, so that you can keep the execute bits on directories.

> The *EXPLICIT* purpose is for *EVERYONE* to absolutely free
> unfettered access to the files on that partition.
> Think of it as a message board in the local grocery where anyone
> could post anything. Advertising flyers with tear off phone numbers
> included.

Of course, I have to add here that I don't understand why users
other than 0 and 1000 need write access when you're carrying out
your experiments on installation. I thought this isolated machine
only had you as a user.

> >Alternatively, use a real filesystem that supports permissions
> >better (i.e. at all). vfat is horrid in many, many ways.
> >
> 
> This machine doesn't have Windows on it. But I'll want to do the
> same thing on one with both Linux and Windows.
> 
> Ideas?

Developing a more secure methodology would be transferrable to other,
connected machines and so provide a richer learning experience.

Cheers,
David.

[toc] | [prev] | [standalone]

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

csiph-web