bug#17495: chgrp: mention of being a member of the target group
Wouter Thielen wrote: Here is a very common usecase: sudo chgrp www-data dir in a deployment script. Hmm... Why are you often changing files to www-data? That is usually the process id that owns the web server process. Usually running apache or nginx or other web process. It is chosen specifically to avoid having it have the ability to write any files on disk as a security layer. Therefore you would normally never have files on disk owned by www-data. That is the security layer that the unique id provides. May I ask what you are doing that needs this? Perhaps we would suggest an alternative configuration. If you want to store files from the web server then of course that directory needs to be writable by the www-data user. But that is usually a one time setup change and then never again and it sounds like you are doing more than this and often. I fear that you are changing files served by a web browser to be the www-data user and that would allow a crack in the web server process to write to the DocumentRoot. That would be bad. Although many PHP projects require just that type of configuration which sets them up for many security problems. For example Wordpress is notorious for security breaches because of such configurations. I have always used sudo with this because I didn't know why I was getting an operation permitted error when doing so. Until I found out that if the effective user is a member of the target group www-data, the sudo isn't needed. Since sudo gives you root permission (in the simple configuration) that is the highest priviledge. I always recommend to use the lowest priviledge needed to perform a task. It is safer. But few people care about safety. I often see recommendations in blogs and articles that say to use root because that is the simplest way to grab the biggest hammer in the toolbox and pound away. That isn't so nice. But people do it all of the time anyway. For example: You mention www-data so perhaps you are using Debian? In Debian /usr/local is group 'staff' so a member of group staff can work there without needing sudo. That is very nice. Unfortunately other systems don't set that up by default. The Wikipedia clearly says that: The *chgrp* (from *ch*ange *gr*ou*p*) commandhttp://en.wikipedia.org/wiki/Command_(computing) may be used by unprivileged http://en.wikipedia.org/wiki/Privilege_(Computing) users on Unix-like http://en.wikipedia.org/wiki/Unix-like systems to change the group associated with a file system object (such as a file, directory, or link) *to one of which they are a member*. I am wondering why the chgrp manpage or info pages do not mention anything about that. It would be very helpful to add that piece of very crucial information to the manpage/info pages. What capabilities the user has and can do with chown, chgrp, chmod, and so forth is a system dependent system policy. The GNU coreutils have traditionally been portable to many different operating systems. The list of operating systems goes on and on. Different operating systems have different requirements. It is rather difficult to document all of the idiosyncratic behavior of every operating system. Generally when operating system policy is not documented by the coreutils that is the reason why. I am not saying that it wouldn't be useful to somehow document this system dependent behavior. You asked why it wasn't and that is what I am answering. If you have suggestions or patches to the documentation that improve the existing state that is always appreciated. But note that writing good documentation is harder than it sounds. Would you like to suggest an improvement to the docs? Bob
bug#17503: df (GNU coreutils) 8.21 not reporting for hfsplus ?
On Thu, May 15, 2014 at 3:28 PM, crquan crq...@gmail.com wrote: I found my df has a bug not showing entry for this /dev/sda2 hfsplus partition, this entry really exists in /proc/mounts and /etc/mtab, but df doesn't report it, I'm not sure if this is specific to hfsplus? or because of the mountpoint /media/user/Macintosh\040HD has a space? and /etc/mtab read it as /media/user/Macintosh\134040HD, is that a bug of mount program as well? This is Linux mint running on a mac laptop, mint ~ # grep hfsplus /proc/mounts /etc/mtab /proc/mounts:/dev/sda2 /media/user/Macintosh\040HD hfsplus ro,nosuid,nodev,relatime,umask=22,uid=0,gid=0,nls=utf8 0 0 /etc/mtab:/dev/sda2 /media/user/Macintosh\134040HD hfsplus ro,nosuid,nodev,relatime,umask=22,uid=0,gid=0,nls=utf8 0 0 Sorry, I feel it's more of a mount program's problem, If I manually edit /etc/mtab of this line to /dev/sda2 /media/user/Macintosh\040HD hfsplus ro,nosuid,nodev,relatime,umask=22,uid=0,gid=0,nls=utf8 0 0 Then df can report this partition with no problem. mint ~ # df -Th |grep hfsplus /dev/sda2 hfsplus 94G 73G 21G 78% /media/user/Macintosh HD
bug#17503: df (GNU coreutils) 8.21 not reporting for hfsplus ?
I found my df has a bug not showing entry for this /dev/sda2 hfsplus partition, this entry really exists in /proc/mounts and /etc/mtab, but df doesn't report it, I'm not sure if this is specific to hfsplus? or because of the mountpoint /media/user/Macintosh\040HD has a space? and /etc/mtab read it as /media/user/Macintosh\134040HD, is that a bug of mount program as well? This is Linux mint running on a mac laptop, mint ~ # grep hfsplus /proc/mounts /etc/mtab /proc/mounts:/dev/sda2 /media/user/Macintosh\040HD hfsplus ro,nosuid,nodev,relatime,umask=22,uid=0,gid=0,nls=utf8 0 0 /etc/mtab:/dev/sda2 /media/user/Macintosh\134040HD hfsplus ro,nosuid,nodev,relatime,umask=22,uid=0,gid=0,nls=utf8 0 0 mint ~ # df |grep sda2 mint ~ # df -Th |grep hfs mint ~ # df --version df (GNU coreutils) 8.21 Copyright (C) 2013 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later http://gnu.org/licenses/gpl.html. This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. Written by Torbjörn Granlund, David MacKenzie, and Paul Eggert. mint ~ # mint ~ # mount --version mount from util-linux 2.20.1 (with libblkid and selinux support) mint ~ # Thanks,
bug#17505: Interface inconsistency, use of intelligent defaults.
On programs that allow input and output by specifying computer-base2 powers
of K/M/G OR decimal based powers of 10,
If the input units are specified in in powers of 2 then the output should be
given in the same units.
Example:
dd if=/dev/zero of=/dev/null bs=256M count=2
... So 512MB, total -... but what do I see:
536870912 bytes (537 MB) copied, 0.225718 s, 2.4 GB/s
Clearly 256*2 != 537.
At the very least this violates the design principle of 'least surprise'
and/or 'least astonishment'.
The SI suffixes are a pox put on us bye the disk manufacturers because
they wanted to pretend to have 2GB or 4GB drives, when they really
only have 1.8GB, or 1907MB.
Either way, disks are created in powers of 512 (or 4096) byte sectors,
, so while you can exactly specify sizes in powers of 1024, you can't
do the same with powers of 1000 (where the result mush be some multiple of
or 4096 for some new disks).
If I compare this to df, and see my disk taking 2G, then I should
be able to xfer it to another 2G disk but this is not the case
do to immoral actions on the part of diskmakers. People knew, at the time,
that 9600 was a 960 character/second -- it was a phone communication speed
where decimal was used, but for storage, units were expressed in multples
of 512 (which the power-of-10 prefixes are not).
(Yes, I know for official purposes, and where the existing established
held sway before the advent of computers, metric-base-10 became understood
as power of 10 based, but in computers, there was never confusion until
disk manufacturers tried to take advantage of people.
Memory does not come in 'kB' mB or gB (kmg=10^(3*{1,2,3}).. it comes
in sizes of KB/MB/GB or (KMG=2^10**{1,2,3}).
But this isn't about changing all unit everywhere... but maintaining
consistency with the units the user used on input (where such can be
verified).
Reasonable? Or are inconsistent results more reasonable?
;-)
bug#17503: df (GNU coreutils) 8.21 not reporting for hfsplus ?
tag 17503 + notabug close 17503 stop On 05/16/2014 12:48 AM, crquan wrote: On Thu, May 15, 2014 at 3:28 PM, crquan crq...@gmail.com wrote: I found my df has a bug not showing entry for this /dev/sda2 hfsplus partition, this entry really exists in /proc/mounts and /etc/mtab, but df doesn't report it, I'm not sure if this is specific to hfsplus? or because of the mountpoint /media/user/Macintosh\040HD has a space? and /etc/mtab read it as /media/user/Macintosh\134040HD, is that a bug of mount program as well? This is Linux mint running on a mac laptop, mint ~ # grep hfsplus /proc/mounts /etc/mtab /proc/mounts:/dev/sda2 /media/user/Macintosh\040HD hfsplus ro,nosuid,nodev,relatime,umask=22,uid=0,gid=0,nls=utf8 0 0 /etc/mtab:/dev/sda2 /media/user/Macintosh\134040HD hfsplus ro,nosuid,nodev,relatime,umask=22,uid=0,gid=0,nls=utf8 0 0 Sorry, I feel it's more of a mount program's problem, If I manually edit /etc/mtab of this line to /dev/sda2 /media/user/Macintosh\040HD hfsplus ro,nosuid,nodev,relatime,umask=22,uid=0,gid=0,nls=utf8 0 0 Then df can report this partition with no problem. mint ~ # df -Th |grep hfsplus /dev/sda2 hfsplus 94G 73G 21G 78% /media/user/Macintosh HD Thanks for the information. Is /etc/mtab a regular file on your system? It should be a symlink nowadays: $ ls -ldog /etc/mtab lrwxrwxrwx 1 17 Feb 20 00:04 /etc/mtab - /proc/self/mounts Having mount to update mtab as a regular file is deprecated: from Karel Zak's (the util-linux maintainer) blog: Yeah, mtab is evil. http://karelzak.blogspot.de/2011/04/bind-mounts-mtab-and-read-only.html as you pointed out that there is not a problem with df, I'm marking this as notabug in coreutils' bug tracker. Thanks have a nice day, Berny
