Re: Copying file has unexpected side effect
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.
Reply to: