Page 2 of 2 FirstFirst 12
Results 11 to 14 of 14

Thread: /home/user Permissions?

  1. #11

    Default Re: /home/user Permissions?

    Are you even on a multi-user machine ... or is this your home desktop ...

  2. #12
    Join Date
    Jun 2008
    Location
    Netherlands
    Posts
    24,732

    Default Re: /home/user Permissions?

    Quote Originally Posted by xorbe View Post
    Are you even on a multi-user machine ... or is this your home desktop ...
    A Linux system is always a multi user system.
    When you forget that (or do not understand that) you will from time to time have difficulties to understand your system.
    Henk van Velden

  3. #13
    Join Date
    Feb 2010
    Location
    Germany
    Posts
    2,422

    Default Re: /home/user Permissions?

    Quote Originally Posted by hcvv View Post
    The above example is contrary to what I say, but I see this as a very special case that will not be repeated by many.
    It is, as you say an example; but, UNIX®, and Linux, and anything else that looks or smells like UNIX®, has all these permissions on files;
    Regardless of the type of file -- a "regular" file or, a directory (file) or, a socket (file) or, whatever else.
    It is, IMHO, important that, anyone learning UNIX® file permissions needs to be aware of all the permission mechanisms which UNIX® provides for files.


    Quote Originally Posted by hcvv View Post
    And I have also the idea that only the system manager is using those "group users" (their passwords being unknown to the real end-users) and thus will do so from the CLI.
    One of the beauties of UNIX® user definitions is that, pseudo-users can be defined which defeat an attempts to login as that user -- the shell is either '/usr/sbin/nologin' or '/bin/false' -- the user's entry in '/etc/shadow' is empty, except for the 'login name' and 'encrypted password' fields -- the password field is either set to the value "!" or "*" -- an invalid result of 'crypt'.

    Take a look at a typical 'passwd' file -- there's a sack full of password-less, impossible to login to, pseudo-users, for example (just a few):
    Code:
    messagebus:x:498:496:User for D-Bus:/run/dbus:/bin/false
    mysql:x:60:484:MySQL database admin:/var/lib/mysql:/bin/false
    nagios:x:383:471:User for Nagios:/var/lib/nagios:/bin/false
    nm-openvpn:x:382:469:NetworkManager user for OpenVPN:/var/lib/openvpn:/sbin/nologin
    ntp:x:74:495:NTP daemon:/var/lib/ntp:/bin/false
    polkitd:x:494:492:User for polkitd:/var/lib/polkit:/sbin/nologin
    postfix:x:51:51:Postfix Daemon:/var/spool/postfix:/bin/false
    pulse:x:489:488:PulseAudio daemon:/var/lib/pulseaudio:/sbin/nologin
    quagga:x:485:482:Quagga routing daemon:/run/quagga:/usr/bin/false
    Exactly this approach, can also be used to manage the "home" directories of groups of users which need to be isolated from one another.

    Where is this approach useful on a private, non-business, machine?
    1. Users for home banking (HBCI) transactions -- isolation from the "normal" login used for e-Mail and other WWW sessions.
    2. Users for the management of club members and finances -- also HBCI transactions and, data privacy issues -- legal, laws of the land, tax department issues -- somewhat easier if a dedicated machine is used . . .
    3. Users which need to run a VM with MS Windows in it because, your camera's manufacturer doesn't supply a RAW file application for Linux -- currently only those folks who own a SIGMA camera and, haven't, yet, purchased a Mac Pro, are affected by this . . .

    Actually, running Digikam and, maintaining the Digikam database, in a user environment isolated from the "normal" user is actually super comfortable and relaxed -- no worries that a stupid mistake while messing about with the system will wipe your collection (of possibly thousands) of photos . . .

  4. #14
    Join Date
    Feb 2010
    Location
    Germany
    Posts
    2,422

    Default Re: /home/user Permissions?

    Quote Originally Posted by tannington View Post
    Found whilst looking for the original bug report:
    https://cgit.kde.org/kio.git/commit/...f6dc14b2d54a06
    There's a comment from me on the related KDE Bug Report 365795 "Setting extended permissions do not work":
    The change made means that the extended permission bits are no longer clobbered but, the original issue reported, remains.
    The KDE developer's final comment is:
    but in any case better than the status quo
    The root cause is, the current inability of the Qt WebKit to support the UNIX® extended permission bits of UNIX® files.
    There are rumours that, this will be addressed with a future release of Qt but, not yet . . .

Page 2 of 2 FirstFirst 12

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •