Re: hostname of the modem gateway
On 1/2/2018 8:16 AM, john doe wrote: On 1/2/2018 8:01 AM, Tom Furie wrote: On Tue, Jan 02, 2018 at 07:52:31AM +0100, john doe wrote: My default route is not 192.168.1.1 and host(1) gives me that same error. What the error actually means is that there is no reverse DNS resolution for that IP address, in other words the IP address cannot be resolved to its hostname. It has nothing at all to do with routing. The OP has said that he want it to get the hostname of his upstream router/gateway. 'ip -r r' will show the FQDN of his default route (192.168.1.1) in that case. Rereading the all conversation I should have said to "David Wright " that the error: $ host 192.168.1.1 Host 1.1.168.192.in-addr.arpa. not found: 3(NXDOMAIN) Meens that there is no hostname associated with that ip. But in the case of the OP it should work. -- John Doe
Re: hostname of the modem gateway
On 1/2/2018 8:01 AM, Tom Furie wrote: On Tue, Jan 02, 2018 at 07:52:31AM +0100, john doe wrote: My default route is not 192.168.1.1 and host(1) gives me that same error. What the error actually means is that there is no reverse DNS resolution for that IP address, in other words the IP address cannot be resolved to its hostname. It has nothing at all to do with routing. The OP has said that he want it to get the hostname of his upstream router/gateway. 'ip -r r' will show the FQDN of his default route (192.168.1.1) in that case. -- John Doe
Re: hostname of the modem gateway
On Tue, Jan 02, 2018 at 07:52:31AM +0100, john doe wrote: > My default route is not 192.168.1.1 and host(1) gives me that same error. What the error actually means is that there is no reverse DNS resolution for that IP address, in other words the IP address cannot be resolved to its hostname. It has nothing at all to do with routing. Cheers, Tom -- Man is a rational animal who always loses his temper when he is called upon to act in accordance with the dictates of reason. -- Oscar Wilde signature.asc Description: Digital signature
Re: hostname of the modem gateway
On 1/2/2018 7:45 AM, Tom Furie wrote: On Tue, Jan 02, 2018 at 07:38:54AM +0100, john doe wrote: Looks like 192.168.1.1 is not your default route. What led you to that conclusion? My default route is not 192.168.1.1 and host(1) gives me that same error. -- John Doe
Re: hostname of the modem gateway
On Tue, Jan 02, 2018 at 07:38:54AM +0100, john doe wrote: > Looks like 192.168.1.1 is not your default route. What led you to that conclusion? Cheers, Tom -- A good scapegoat is hard to find. A guilty conscience is the mother of invention. -- Carolyn Wells signature.asc Description: Digital signature
Re: hostname of the modem gateway
On 1/2/2018 7:15 AM, David Wright wrote: On Tue 02 Jan 2018 at 06:25:29 (+0100), john doe wrote: On 1/2/2018 12:12 AM, Max Power wrote: Hi guys, with the new release of Debian 'Stretch', the route command has been replaced but what other command returns the hostname of the modem/router gateway...? # route gateway = home.telecomitalia.it # ip route gateway = 192.168.1.1 $ ip -r r You need to ask for the resolver with -r. man ip-route documents the arguments/commands, but you need man ip for the options (which are common). Thanks for reply, Max Power. You could try the host(1) utility: $ host 192.168.1.1 https://linux.die.net/man/1/host $ host 192.168.1.1 Host 1.1.168.192.in-addr.arpa. not found: 3(NXDOMAIN) $ Looks like 192.168.1.1 is not your default route. -- John Doe
Re: hostname of the modem gateway
On Tue 02 Jan 2018 at 06:25:29 (+0100), john doe wrote: > On 1/2/2018 12:12 AM, Max Power wrote: > >Hi guys, > >with the new release of Debian 'Stretch', the route command has been replaced > >but what other command returns the hostname of the modem/router gateway...? > ># route > >gateway = home.telecomitalia.it > ># ip route > >gateway = 192.168.1.1 $ ip -r r You need to ask for the resolver with -r. man ip-route documents the arguments/commands, but you need man ip for the options (which are common). > > > >Thanks for reply, Max Power. > > > > You could try the host(1) utility: > > $ host 192.168.1.1 > > https://linux.die.net/man/1/host $ host 192.168.1.1 Host 1.1.168.192.in-addr.arpa. not found: 3(NXDOMAIN) $ Cheers, David.
Re: hostname of the modem gateway
On 1/2/2018 12:12 AM, Max Power wrote: Hi guys, with the new release of Debian 'Stretch', the route command has been replaced but what other command returns the hostname of the modem/router gateway...? # route gateway = home.telecomitalia.it # ip route gateway = 192.168.1.1 Thanks for reply, Max Power. You could try the host(1) utility: $ host 192.168.1.1 https://linux.die.net/man/1/host -- John Doe
Re: Experiences with BTRFS -- is it mature enough for enterprise use?
On 12/31/17 14:45, Sven Hartge wrote: David Christensen wrote: $ man 4 md SCRUBBING AND MISMATCHES ... If check was used, then no action is taken to handle the mismatch, it is simply recorded. If repair was used, then a mismatch will be repaired in the same way that resync repairs arrays. For RAID5/RAID6 new parity blocks are written. For RAID1/RAID10, all but one block are overwritten with the content of that one block. I wonder how md picks "that one block"? Only if one drives reports an error. Then data from the good block is used to overwrite the bad block, hoping the drive remaps the sector and everything is fine again. If both devices report no error but differing data has been read, MD-RAID1 can't know which block is good. MD-RAID5/6 could calculate all parity combinations and use the data a majority agrees upon. (I don't know if it does it, though). I tried looking at the Kernel RAID code, but I must admit: it is all Esperanto to me, the code is far too low level for me to understand. That's why "programming systems product" [1] includes architectural, functional, design, construction, etc., documentation. FreeBSD is better is this regard [2]. David [1] https://www.pearson.com/us/higher-education/program/Brooks-Mythical-Man-Month-The-Essays-on-Software-Engineering-Anniversary-Edition-2nd-Edition/PGM172844.html [2] https://www.pearson.com/us/higher-education/program/Mc-Kusick-Design-and-Implementation-of-the-Free-BSD-Operating-System-The-2nd-Edition/PGM224032.html
Re: How to relocate LVM pv to make room for grub install
On 01/01/2018 02:46 AM, Pascal Hambourg wrote: > Le 01/01/2018 à 06:51, Tom Dial a écrit : >> Upgrading a workstation from Jessie to Stretch I found that the original >> disk partitioning left insufficient space for grub (re)install. The >> system has two identical ~233 GiB disks, sda and sdb, partitioned >> identically: >> >> Disk /dev/sda: 232.9 GiB, 250059350016 bytes, 488397168 sectors >> Units: sectors of 1 * 512 = 512 bytes >> Sector size (logical/physical): 512 bytes / 512 bytes >> I/O size (minimum/optimal): 512 bytes / 512 bytes >> Disklabel type: dos >> Disk identifier: 0x00015e37 >> >> Device Boot Start End Sectors Size Id Type >> /dev/sda1 * 63 122077934 122077872 58.2G 8e Linux LVM >> /dev/sda2 122077935 244155869 122077935 58.2G 8e Linux LVM >> /dev/sda3 244155870 366233804 122077935 58.2G 8e Linux LVM >> /dev/sda4 366233805 488392064 122158260 58.3G 8e Linux LVM > > This partition table must have been created a long time ago. At the time > of Jessie, current partitioning tools would have aligned partitions on > 1-MiB boundaries instead of cylinder boundaries, leaving plenty of room > for GRUB's core image. Yes: March, 2008; Etch installed then, later upgraded successively to Lenny, Squeeze, Wheezy, and Jessie without major difficulty. > >> sda1 and sdb2 form a volume group with active LVs containing OS and >> data; sdb1 underpins a vg containing additional data. The other >> partitions, sda2-sda4 and sdb3-sdb4, are not used at present, but are >> configured as lvm physical volumes. > > Do you mean that they are not part of any volume group ? Correct. > >> Gparted is installed and I used it >> to move these partitions toward the end of the disks, so that the maps >> now are: >> >> Device Boot Start End Sectors Size Id Type >> /dev/sdb1 63 122077934 122077872 58.2G 8e Linux LVM >> /dev/sdb2 122077935 244155869 122077935 58.2G 8e Linux LVM >> *gap 244155870 244162559 6690 3.2M >> /dev/sdb3 244162560 366239743 122077184 58.2G 8e Linux LVM >> /dev/sdb4 366239744 488397167 122157424 58.3G 8e Linux LVM >> >> and >> >> Device Boot Start End Sectors Size Id Type >> /dev/sda1 * 63 122077934 122077872 58.2G 8e Linux LVM >> *gap 122077935 122085375 7441 3.6M >> /dev/sda2 122085376 244162559 122077184 58.2G 8e Linux LVM >> /dev/sda3 244162560 366239743 122077184 58.2G 8e Linux LVM >> /dev/sda4 366239744 488397167 122157424 58.3G 8e Linux LVM > > Which is the boot disk ? /dev/sda > >> If I understand correctly, I should now be able to boot with a rescue >> disk or USB key that has lvm, and move sdb2, sdb1, and sda1 similarly, >> leaving several megabytes free at the beginning of each disk.> > LVM tools cannot move partitions. pvmove does not move PV, it just moves > LV data between PVs. You need Gparted to move partitions (and their > contents). Of course you need to run Gparted from a system which does > not use the partitions to be moved. Thanks for the correction. I might have caught the error, or might not. > >> 1. the core.img file is 31952 bytes, apparently 208 bytes too long. Is >> there a way to shorten it by that much without sacrificing the >> capability to boot from an lvm logical volume and jfs file systems? > > Hardly. The core image must include necessary modules to read > /boot/grub, including the partition table, lvm and the filesystem. You > could move /boot/grub to a new LV with another filesystem type requiring > less space in the core image. Checking the modules sizes, jfs.mod is > slightly bigger than ext2.mod (by 156 bytes so I'm afraid it would not > be enough). Smaller modules are fat.ko and minix*.ko. I have never used > Minix filesystem, but I know GRUB can be installed on FAT, even though > it does nogt sound very satifactory. > > Other options : > > - Move /boot/grub to a non-LVM partition. But I am not sure that the > free 3.6 MiB on your disks will be enough even with a light filesystem. > > - Install GRUB boot and core images in a btrfs non-LVM partition, which > supports GRUB embedding, instead of in the MBR. However IME the minimum > partition size for btrfs is at least 5 MiB (or 16 MiB, depending on > btrfs tools version). > > - Convert the partition table to GPT with gdisk and create a "BIOS boot" > partition which GRUB can use to write the core image. However since you > moved partitions to the very end of the disk there is no room any more > to write the backup GPT partition table. > >> 2. The grub install failed. The current modified grub.cfg was not >> changed materially and references most objects by uuid. If I shut down >> and move the necessary partitions, is the system likely to boot >> successfully using the (hopefully unchanged) original grub installation, >> so that I could simply move the pv partitions, reboot normally, run >> grub-install, and then continue upgrading? >
hostname of the modem gateway
Hi guys, with the new release of Debian 'Stretch', the route command has been replaced but what other command returns the hostname of the modem/router gateway...? # route gateway = home.telecomitalia.it # ip route gateway = 192.168.1.1 Thanks for reply, Max Power.
Re: [ADDENDUM] File permission confusion [Debian 9.1 with MATE]
On Mon 01 Jan 2018 at 05:37:15 -0600, Richard Owlett wrote: > On 01/01/2018 05:23 AM, Richard Owlett wrote: > > As user "richard" I created 3 files. > > I later wanted to protect them totally from accidental change. > > For each file, I went to Properties->Permissions and changed Access for > > Owner, Group, and Others to "Read Only". > > As user "richard" I was able to delete them with Caja. > > *UNDESIRABLE* > > As "root" I changed Owner and Group to "root" leaving Access for all as > > "Read Only". > > > > User "richard" could still *DELETE THEM*! > > "Read Only" evidently does not mean what it implies. > > > > What's happening? > > TIA > > Logged into Debian as "richard" SeaMonkey was able to change contents of > those files. > > HELP! > That is EXACTLY what I was trying to prevent. It's your house - you can do whatever you want in it. You can put labels on bottles of wine which say "do not drink before February 2018". Then you can ignore them! :). Life's like that. You invite someone into your house; don't give them the key to your drinks cupboard. "Drink only" for the owner. :) You want to prevent yourself opening the cupboard? Either try to exercise some self-control or hide the key somewhere you are likely to forget about (not that you will and, in any case, thers's nothing a good hammar cannot readjust). Cease wanting to be nannied and cosseted by the OS and having your every actions constrained by external agents. Debian lets you do what *you* want in your home directory. You've just deleted a file you desperately wanted to keep? Never mind, Next time you might think more clearly. -- Brian.
Re: File permission confusion [Debian 9.1 with MATE]
Hi, Richard Owlett > I used "linux tutorial chmod chattr" [w/o quotes] in both DuckDuckGo and > Google. A general search topic would be "linux file permissions" and "chattr". I can show you an example shell session on an ext4 filesystem. I create a directory with a file and take away w-permissions: $ cd /home/thomas/test $ mkdir my_private_dir $ echo private_content >my_private_dir/my_private_file $ chmod a-w my_private_dir/my_private_file $ chmod a-w my_private_dir Now normal users including myelf cannot change the file content and cannot rename or remove the file $ echo new_content >my_private_dir/my_private_file bash: my_private_dir/my_private_file: Permission denied $ mv my_private_dir/my_private_file my_private_dir/renamed_private_file mv: cannot move ‘my_private_dir/my_private_file’ to ‘my_private_dir/renamed_private_file’: Permission denied $ rm my_private_dir/my_private_file rm: cannot remove ‘my_private_dir/my_private_file’: Permission denied But the superuser can override this without needing to use chmod # cd /home/thomas/test # echo foul >> my_private_dir/my_private_file # cat my_private_dir/my_private_file private_content foul # mv my_private_dir/my_private_file my_private_dir/renamed_private_file # ls -l my_private_dir total 4 -r--r--r-- 1 thomas thomas 21 Jan 1 18:58 renamed_private_file Now comes "chattr +i". Only the superuser can apply it. After restoring the old filename and content, i do: # chattr +i my_private_dir/my_private_file This keeps even the superuser from spoiling the file # echo foul >> my_private_dir/my_private_file bash: my_private_dir/my_private_file: Permission denied # mv my_private_dir/my_private_file my_private_dir/renamed_private_file mv: cannot move ‘my_private_dir/my_private_file’ to ‘my_private_dir/renamed_private_file’: Operation not permitted The protection does not depend on missing w-permissions of the directory: # chmod u+w my_private_dir # rm my_private_dir/my_private_file rm: cannot remove ‘my_private_dir/my_private_file’: Operation not permitted or missing w-permissions of the file file: # chmod u+w my_private_dir/my_private_file chmod: changing permissions of ‘my_private_dir/my_private_file’: Operation not permitted even if the superuser temporarily allows the change and them runs "chattr +i" again: # chattr -i my_private_dir/my_private_file # chmod u+w my_private_dir/my_private_file # chattr +i my_private_dir/my_private_file # echo foul >> my_private_dir/my_private_file bash: my_private_dir/my_private_file: Permission denied -- I can of course not comment on what particular GUI tools do when they promise the user to make something "Read-only". (... or what systemd is willing to do for its clients ) Have a nice day :) Thomas
Re: File permission confusion [Debian 9.1 with MATE]
On Mon, Jan 01, 2018 at 07:13:19PM +0100, to...@tuxteam.de wrote: The nice thing about chattr is that you can protect the file's directory entry (which one?) from being deleted. But I agree that using chattr without having first understood chmod is like using a circular saw without having first mastered the screwdriver. Not recommended :-) It also requires superuser, so it isn't going to help at the user level. There is nothing a user can do to *prevent* himself from destroying his own files, but simply removing write permission from the file & directory will keep it from happening accidentally (he could still put back write permission and delete/modify the file). Mike Stone
Re: File permission confusion [Debian 9.1 with MATE]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mon, Jan 01, 2018 at 06:11:59PM -, Dan Purgert wrote: [...] > Note that "write" permissions on a file only really comes into play when > you're messing with a file in an editor (e.g. vim, emacs, nano, > whatever). It does not necessarily prevent one from doing something > like: > >-rw-r- [...] somefile.txt >$ mv anotherfile.txt somefile.txt > > Because you're not modifying "the file", but rather its parent > directory. It's a very, very fine distinction, to be sure. And that's the point... a program "messing" with the file might well choose to copy the file to some other name, modify that copy, and then, at the end, remove the original and rename the new version to the original name: this is actually a common pattern to achieve some form of "atomicity": when you want either all the changes "committed to disk" or none (in case of failure). As long as the basic difference between a file and its "name" (i.e. the directory entry "pointing" to the file) is not understood, this fine difference between writing to the file and modifying (e.g. deleting) the directory entry will seem mysterious. Otherwise... nice tutorial. Cheers - -- t -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iEYEARECAAYFAlpKfhoACgkQBcgs9XrR2kbJZACggJJacqgUGuj9Hc6tVjRzWycw 8t4An069sCaghVj3PynydUgoghliVEey =88r8 -END PGP SIGNATURE-
Re: File permission confusion [Debian 9.1 with MATE]
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Richard Owlett wrote:
> [...]
> I need a tutorial. Man pages are unsatisfactory. Sort of like giving
> someone a dictionary and expecting them to become competent writers.
In brief:
chmod - change "mode" bits (i.e. read / write / execute) based on
whether a user is the owner, part of the owning group, or neither. Skip
to `CHMOD' for more detail (or scroll down about 6-7 lines)
chattr - change "attribute" bits (i.e. make it immutable, only allow
appends, many other things - see the manpage for all possibilities).
Skip to `CHATTR' for more detail (or scroll down about 65-70 lines)
CHMOD:
The output of ls -l shows these mode bits in the leftmost column. The
format is [directory flag] [owner permissions] [group permissions]
[other permissions]; for example "-rwxr-xr--" for a non-directory file
that
- the owner can read from, write to, or execute
- the owning group can read from, or execute
- anyone else can read
Note that "write" permissions on a file only really comes into play when
you're messing with a file in an editor (e.g. vim, emacs, nano,
whatever). It does not necessarily prevent one from doing something
like:
-rw-r- [...] somefile.txt
$ mv anotherfile.txt somefile.txt
Because you're not modifying "the file", but rather its parent
directory. It's a very, very fine distinction, to be sure.
For directories, it's a little more ... nuanced. A directory with
"dwrxr-xrw-" for example means
- the owner can read directory contents ("ls"), write new files to /
delete old files from the directory, and execute (cd into) it.
- the group can list the directory contents, cd into it; and (if
file-level permissions allow) read files; the group CANNOT create new
files, delete files, etc.
- Everyone else can do absolutely nothing, since they're not allowed to
execute any commands on the directory.
Now, there are also some "special" bits for chmod, such as the setuid /
setgid bit, or the sticky bit.
Setting the setuid / setgid bit on a file means that when an executable
file is run, it is run with the user (or group) permissions. For
example, the ping command:
-rwsr-xr-x 1 root root [...] /bin/ping
this means that ANYONE running the 'ping' command will invoke it with
the permissions of the owner (i.e. root), rather than whatever
permissions their user may have. This is required as `ping' needs to
send (and receive) packets on a network interface (and only root can do
that).
The "Sticky Bit" is a file and directory flag that means pretty much the
same thing, but again, there is a fine distinction when set on a
directory.
- files having the sticky bit can only be renamed / deleted by the
owning person (user ID)
- directories having the sticky bit can only be renamed / deleted by
the owning person (user ID) OR the owner of the directory itself.
Note that root supercedes all of these restrictions - root can cd into
non-executable directories, root can alter files with the sticky bit
set, and so on.
CHATTR:
This one gets fun - and may be more what you're looking for in terms of
making the files "unchangeable by anyone".
Instead of modes (permissions), attributes on the file are metadata that
tell the filesystem itself what is allowed to happen with a file, and
these supercede modes.
If you're coming from a Windows background, you'll probably recognize
the attributes:
- Archive -- File was edited since last backup operation. Include with
the next backup run.
- Hidden -- Hidden file, do not show in Windows Explorer / DOS `dir'
command (unless option set). Equivalent to a dotfile in Linux
- System -- "Special" hidden file, do not show in Windows Explorer /
DOS `dir' command (unless option set). No real linux equivalent that
I can think of.
- Read-Only -- File cannot be altered, unless application *explicitly*
asks (probably run by Administrator). Linux equivalent is chattr +i
(set file to be immutable).
- Compressed - NTFS filesystem only. "Compress filesystem to save
space" or whatever it was.
- Encrypted - file is encrypted by the file system on save (IIRC,
NTFS-only)
- Not Indexed - Tell Windows Search to not index the file / directory.
The chattr manpage lists out everything that it lets you do. There are
quite a number of options (14+ at a quick glance), some of which you'll
find correspond to the Windows / DOS ones above.
> I used "linux tutorial chmod chattr" [w/o quotes] in both DuckDuckGo and
> Google. Many were as much use as the dictionary.
Nah, most (all) of those so-called tutorials completely fail at being
tutorials. A dictionary at least always fulfills its stated function
(at least when considering words agreed upon as words, rather than
slang, etc.).
If anything, I'd bet the Arch wiki's page[1], coupled with any external
links (e.g. wikipedia) would be what kind of information you're after
(although, they may be a bit light on the "tutorial" aspect for
Re: File permission confusion [Debian 9.1 with MATE]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mon, Jan 01, 2018 at 01:01:50PM -0500, Michael Stone wrote: > And forget chattr, it's just going to confuse things. The nice thing about chattr is that you can protect the file's directory entry (which one?) from being deleted. But I agree that using chattr without having first understood chmod is like using a circular saw without having first mastered the screwdriver. Not recommended :-) Cheers - -- t -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iEYEARECAAYFAlpKej8ACgkQBcgs9XrR2kYmOQCfRrEB4V318LVCQQDyFm7pSWW6 DKAAn1duJiG//ltHyQf6XcuPf/qASjXz =sCnT -END PGP SIGNATURE-
Re: File permission confusion [Debian 9.1 with MATE]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mon, Jan 01, 2018 at 11:49:01AM -0600, Richard Owlett wrote: [...] > It's one of those theory and ability to apply. > That's why I asked for pointer suitable tutorial. > [https://lists.debian.org/debian-user/2018/01/msg8.html] Roughly in this order: https://en.wikipedia.org/wiki/Inode (or why a "file itself" in unix is very different from the "directory entry", which is just a kind of file name: an idea very foreign to people coming from DOS, who can safely identify a directory entry with a file). Read several times, until it sinks :-) Once you can answer questions like - what happens if you hardlink a file "foo" to a new name "bar", and then delete "foo"? - what happens in the above scenario if you instead do a softlink? - why can't you hardlink across file system boundaries? what about a soft link? - what happens if you hardlink "foo" to "bar" and then change "bar"'s permissions? Once you have the relationships between file, inode and directory entry straight in your head, the rest is comparatively easy: - https://en.wikipedia.org/wiki/Unix_filesystem - https://en.wikipedia.org/wiki/File_system_permissions And yes, a man page is a manual, not a text book. So it's as it is supposed to be :-) A good introductory text (it's a bit old, the implementation details have changed a lot since, but it'll give you a good foundation) is Maurice Bach's "The design of the UNIX operating system": https://archive.org/details/DesignOfTheUnixOperatingSystemByMauriceBach oh, and leave a tip to the great folks at the Internet archive on your way out. Cheers - -- t -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iEYEARECAAYFAlpKeWkACgkQBcgs9XrR2ka+YQCfb6pd42nuPPZnyFe+6zhTnITd vJEAnimui7UO4XLbrILugaUhzrvzFIX7 =qqgm -END PGP SIGNATURE-
Re: File permission confusion [Debian 9.1 with MATE]
And forget chattr, it's just going to confuse things.
Re: File permission confusion [Debian 9.1 with MATE]
On 01/01/2018 11:34 AM, Michael Stone wrote: On Mon, Jan 01, 2018 at 11:28:37AM -0600, Richard Owlett wrote: WHY should one with "Read-only" access be able to delete it? A number of people have already explained that the ability delete requires write permission on the directory containing the file. You don't seem to have acknowledged that. This is the only way the semantics make sense, or else a user would be able to create a file that the owner of the directory would not be able to get rid of. As someone else already posted, when you delete a file you're not really deleting the file--you're removing one of potentially many directory entries in one of potentially many directories. Most people can get by without knowing that, and acting as though the directory entry and the file are unique and related, but if you start trying to manipulate permissions it is important to understand what's actually going on. Mike Stone It's one of those theory and ability to apply. That's why I asked for pointer suitable tutorial. [https://lists.debian.org/debian-user/2018/01/msg8.html]
Re: File permission confusion [Debian 9.1 with MATE]
On Mon, Jan 01, 2018 at 11:28:37AM -0600, Richard Owlett wrote: WHY should one with "Read-only" access be able to delete it? A number of people have already explained that the ability delete requires write permission on the directory containing the file. You don't seem to have acknowledged that. This is the only way the semantics make sense, or else a user would be able to create a file that the owner of the directory would not be able to get rid of. As someone else already posted, when you delete a file you're not really deleting the file--you're removing one of potentially many directory entries in one of potentially many directories. Most people can get by without knowing that, and acting as though the directory entry and the file are unique and related, but if you start trying to manipulate permissions it is important to understand what's actually going on. Mike Stone
Re: File permission confusion [Debian 9.1 with MATE]
On 01/01/2018 10:23 AM, David Wright wrote:
On Mon 01 Jan 2018 at 05:23:29 (-0600), Richard Owlett wrote:
As user "richard" I created 3 files.
I later wanted to protect them totally from accidental change.
For each file, I went to Properties->Permissions and changed Access
for Owner, Group, and Others to "Read Only".
No, you set the access to "Read Permission". Each bit grants a
permission (on the file itself; its directory has to be considered
separately).
As user "richard" I was able to delete them with Caja.
*UNDESIRABLE*
As "root" I changed Owner and Group to "root" leaving Access for all
as "Read Only".
User "richard" could still *DELETE THEM*!
"Read Only" evidently does not mean what it implies.
If you read "Read Only" in Linux documentation you should consider
filing a bug against it.
I wouldn't YET claim a bug against Linux.
I've been seriously considering one against Caja.
Under Caja's Properties->Permissions tab:
1. Owner is given choice of "Read-only" or "Read and Write"
2. Group is given choice of "Read-only" or "Read and Write" or "None"
3. Other is given choice of "Read-only" or "Read and Write" or "None"
WHY should one with "Read-only" access be able to delete it?
The file system of all partitions of this machine is ext4.
As for these "implications", you might be
assuming MSDOS semantics from your past experience.
Prior to too many decades of M$ windows I was command line oriented
using what ever ran a PDP-8 from paper tape, RSX-11M, an Intel
development system for the 8080, a Commodore Personal Electronic
Transactor (aka a PET ;), and later a personal CPM-80 system. All were
inherently single user systems. I then did things the M$ way for about
30 years ;{
Cheers,
David.
Re: installing ufraw on buster
On Sunday, 31 Dec 2017 at 19:53, Brian wrote: > Indeed; especially if you are coming from apt-get. But, if you think > about it, do users want to keep all the debs they have downloaded? I agree: removing the .deb files makes sense for most use cases. > I'm moved to suggest that apt rather than apt-get is the recommended > utility to be advised in debian-user. Fewer keystrokes. :) Not just shorter but easier as well :-) Happy new year! -- Eric S Fraga via Emacs 27.0.50, org 9.1.5 signature.asc Description: PGP signature
Re: File permission confusion [Debian 9.1 with MATE]
On 01/01/2018 06:01 AM, Thomas Schmitt wrote: Hi, Richard Owlett wrote: As user "richard" I was able to delete them with Caja. To prevent renaming or deletion of a file, you need to prevent writing to the directory which hosts it. (Actually you delete the "dirent", which points to the inode. The inode gets deleted when its last dirent is gone and no filedescriptor is open on it any more.) You may prevent writing either by taking away w-permission for everybody chmod a-w directory or by preventing users from removing files which they don't own chmod +t directory But the superuser will probably be able to override both of this without the prior need to change the directory permissions. There is chattr +i file with some filesystems. I dimly remember we had a discussion about its effectiveness a while ago ... Logged into Debian as "richard" SeaMonkey was able to change contents of those files. It is a usual strategy against softlink spoofing to rename or delete the original file and to store the changed content as new file. Have a nice day :) Thomas Color me confused. Using "ls- l ..." to track happened I used "chattr" and "chmod" on the same directory. Unsatisfactory. I need a tutorial. Man pages are unsatisfactory. Sort of like giving someone a dictionary and expecting them to become competent writers. I used "linux tutorial chmod chattr" [w/o quotes] in both DuckDuckGo and Google. Many were as much use as the dictionary. Many had "tutorial" in neither title nor content. Many discussed "chattr" or "chmod" with only a passing mention of the other. Can anyone point to tutorials which: cover both in a single article or a single author with articles on both or a single website with articles on both Thank you.
Re: File permission confusion [Debian 9.1 with MATE]
On Mon 01 Jan 2018 at 05:23:29 (-0600), Richard Owlett wrote: > As user "richard" I created 3 files. > I later wanted to protect them totally from accidental change. > For each file, I went to Properties->Permissions and changed Access > for Owner, Group, and Others to "Read Only". No, you set the access to "Read Permission". Each bit grants a permission (on the file itself; its directory has to be considered separately). > As user "richard" I was able to delete them with Caja. > *UNDESIRABLE* > As "root" I changed Owner and Group to "root" leaving Access for all > as "Read Only". > > User "richard" could still *DELETE THEM*! > "Read Only" evidently does not mean what it implies. If you read "Read Only" in Linux documentation you should consider filing a bug against it. As for these "implications", you might be assuming MSDOS semantics from your past experience. Cheers, David.
Re: File permission confusion [Debian 9.1 with MATE]
Hi, Richard Owlett wrote: > As user "richard" I was able to delete them with Caja. To prevent renaming or deletion of a file, you need to prevent writing to the directory which hosts it. (Actually you delete the "dirent", which points to the inode. The inode gets deleted when its last dirent is gone and no filedescriptor is open on it any more.) You may prevent writing either by taking away w-permission for everybody chmod a-w directory or by preventing users from removing files which they don't own chmod +t directory But the superuser will probably be able to override both of this without the prior need to change the directory permissions. There is chattr +i file with some filesystems. I dimly remember we had a discussion about its effectiveness a while ago ... > Logged into Debian as "richard" SeaMonkey was able to change contents of > those files. It is a usual strategy against softlink spoofing to rename or delete the original file and to store the changed content as new file. Have a nice day :) Thomas
Re: [ADDENDUM] File permission confusion [Debian 9.1 with MATE]
On Mon 01 Jan 2018 at 05:37:15 -0600, Richard Owlett wrote: > On 01/01/2018 05:23 AM, Richard Owlett wrote: > > As user "richard" I created 3 files. > > I later wanted to protect them totally from accidental change. > > For each file, I went to Properties->Permissions and changed Access for > > Owner, Group, and Others to "Read Only". > > As user "richard" I was able to delete them with Caja. > > *UNDESIRABLE* > > As "root" I changed Owner and Group to "root" leaving Access for all as > > "Read Only". > > > > User "richard" could still *DELETE THEM*! > > "Read Only" evidently does not mean what it implies. > > > > What's happening? > > TIA > > Logged into Debian as "richard" SeaMonkey was able to change contents of > those files. > > HELP! > That is EXACTLY what I was trying to prevent. chattr(1). -- Brian.
[ADDENDUM] File permission confusion [Debian 9.1 with MATE]
On 01/01/2018 05:23 AM, Richard Owlett wrote: As user "richard" I created 3 files. I later wanted to protect them totally from accidental change. For each file, I went to Properties->Permissions and changed Access for Owner, Group, and Others to "Read Only". As user "richard" I was able to delete them with Caja. *UNDESIRABLE* As "root" I changed Owner and Group to "root" leaving Access for all as "Read Only". User "richard" could still *DELETE THEM*! "Read Only" evidently does not mean what it implies. What's happening? TIA Logged into Debian as "richard" SeaMonkey was able to change contents of those files. HELP! That is EXACTLY what I was trying to prevent.
Re: File permission confusion [Debian 9.1 with MATE]
On Mon, Jan 01, 2018 at 05:23:29AM -0600, Richard Owlett wrote: > As user "richard" I created 3 files. > I later wanted to protect them totally from accidental change. > For each file, I went to Properties->Permissions and changed Access for > Owner, Group, and Others to "Read Only". > As user "richard" I was able to delete them with Caja. > *UNDESIRABLE* > As "root" I changed Owner and Group to "root" leaving Access for all as > "Read Only". > > User "richard" could still *DELETE THEM*! > "Read Only" evidently does not mean what it implies. > > What's happening? > TIA > BY any chance did user richard own the directory they were in? I think the logic here is that deleting a file involves writing to the directory the file is in, so if you have priveleges to (for example ownership of) the directory, yes you'd be able to delete it. I'd further postulate that in your scenario when the file was owned by root but the directory was owned by richard, richard would not have been able to append to or shorten the file -- because that would have involved writing to the file which richard did not have permissions to do. Mark
File permission confusion [Debian 9.1 with MATE]
As user "richard" I created 3 files. I later wanted to protect them totally from accidental change. For each file, I went to Properties->Permissions and changed Access for Owner, Group, and Others to "Read Only". As user "richard" I was able to delete them with Caja. *UNDESIRABLE* As "root" I changed Owner and Group to "root" leaving Access for all as "Read Only". User "richard" could still *DELETE THEM*! "Read Only" evidently does not mean what it implies. What's happening? TIA
Re: How to relocate LVM pv to make room for grub install
Le 01/01/2018 à 06:51, Tom Dial a écrit : Upgrading a workstation from Jessie to Stretch I found that the original disk partitioning left insufficient space for grub (re)install. The system has two identical ~233 GiB disks, sda and sdb, partitioned identically: Disk /dev/sda: 232.9 GiB, 250059350016 bytes, 488397168 sectors Units: sectors of 1 * 512 = 512 bytes Sector size (logical/physical): 512 bytes / 512 bytes I/O size (minimum/optimal): 512 bytes / 512 bytes Disklabel type: dos Disk identifier: 0x00015e37 Device Boot Start End Sectors Size Id Type /dev/sda1 * 63 122077934 122077872 58.2G 8e Linux LVM /dev/sda2 122077935 244155869 122077935 58.2G 8e Linux LVM /dev/sda3 244155870 366233804 122077935 58.2G 8e Linux LVM /dev/sda4 366233805 488392064 122158260 58.3G 8e Linux LVM This partition table must have been created a long time ago. At the time of Jessie, current partitioning tools would have aligned partitions on 1-MiB boundaries instead of cylinder boundaries, leaving plenty of room for GRUB's core image. sda1 and sdb2 form a volume group with active LVs containing OS and data; sdb1 underpins a vg containing additional data. The other partitions, sda2-sda4 and sdb3-sdb4, are not used at present, but are configured as lvm physical volumes. Do you mean that they are not part of any volume group ? Gparted is installed and I used it to move these partitions toward the end of the disks, so that the maps now are: Device Boot Start End Sectors Size Id Type /dev/sdb1 63 122077934 122077872 58.2G 8e Linux LVM /dev/sdb2 122077935 244155869 122077935 58.2G 8e Linux LVM *gap244155870 244162559 6690 3.2M /dev/sdb3 244162560 366239743 122077184 58.2G 8e Linux LVM /dev/sdb4 366239744 488397167 122157424 58.3G 8e Linux LVM and Device Boot Start End Sectors Size Id Type /dev/sda1 * 63 122077934 122077872 58.2G 8e Linux LVM *gap122077935 122085375 7441 3.6M /dev/sda2 122085376 244162559 122077184 58.2G 8e Linux LVM /dev/sda3 244162560 366239743 122077184 58.2G 8e Linux LVM /dev/sda4 366239744 488397167 122157424 58.3G 8e Linux LVM Which is the boot disk ? If I understand correctly, I should now be able to boot with a rescue disk or USB key that has lvm, and move sdb2, sdb1, and sda1 similarly, leaving several megabytes free at the beginning of each disk. LVM tools cannot move partitions. pvmove does not move PV, it just moves LV data between PVs. You need Gparted to move partitions (and their contents). Of course you need to run Gparted from a system which does not use the partitions to be moved. 1. the core.img file is 31952 bytes, apparently 208 bytes too long. Is there a way to shorten it by that much without sacrificing the capability to boot from an lvm logical volume and jfs file systems? Hardly. The core image must include necessary modules to read /boot/grub, including the partition table, lvm and the filesystem. You could move /boot/grub to a new LV with another filesystem type requiring less space in the core image. Checking the modules sizes, jfs.mod is slightly bigger than ext2.mod (by 156 bytes so I'm afraid it would not be enough). Smaller modules are fat.ko and minix*.ko. I have never used Minix filesystem, but I know GRUB can be installed on FAT, even though it does nogt sound very satifactory. Other options : - Move /boot/grub to a non-LVM partition. But I am not sure that the free 3.6 MiB on your disks will be enough even with a light filesystem. - Install GRUB boot and core images in a btrfs non-LVM partition, which supports GRUB embedding, instead of in the MBR. However IME the minimum partition size for btrfs is at least 5 MiB (or 16 MiB, depending on btrfs tools version). - Convert the partition table to GPT with gdisk and create a "BIOS boot" partition which GRUB can use to write the core image. However since you moved partitions to the very end of the disk there is no room any more to write the backup GPT partition table. 2. The grub install failed. The current modified grub.cfg was not changed materially and references most objects by uuid. If I shut down and move the necessary partitions, is the system likely to boot successfully using the (hopefully unchanged) original grub installation, so that I could simply move the pv partitions, reboot normally, run grub-install, and then continue upgrading? The current state is : - GRUB boot image and core image from Jessie in the MBR and gap - GRUB modules from Stretch in /boot/grub So I am afraid that the core image and modules won't match and GRUB may not boot properly, ending up in the rescue prompt. However it may work if the versions are close enough. GRUB versions in jessie and stretch are much closer than those in wheezy and jessie. 3. The problem occurred at the end of "apt upgrade." The necessary grub c
