Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.debian.user > #229624
| From | Reco <recoverym4n@enotuniq.net> |
|---|---|
| Newsgroups | linux.debian.user |
| Subject | Re: Permissions on NFS mounts |
| Date | 2020-12-10 11:40 +0100 |
| Message-ID | <BkrwB-6Oc-7@gated-at.bofh.it> (permalink) |
| References | (1 earlier) <BkeJ3-7n0-1@gated-at.bofh.it> <Bkqhb-69W-5@gated-at.bofh.it> <BkqKe-6jt-13@gated-at.bofh.it> <BkqTU-6mH-13@gated-at.bofh.it> <Bkr3A-6Fd-7@gated-at.bofh.it> |
| Organization | linux.* mail to news gateway |
On Thu, Dec 10, 2020 at 12:07:54PM +0200, Andrei POPESCU wrote: > On Jo, 10 dec 20, 12:52:56, Reco wrote: > > On Thu, Dec 10, 2020 at 11:46:02AM +0200, Andrei POPESCU wrote: > > > > > > passwd -l/--lock <username> > > > > sudo -u <locked_user> /bin/bash -i > > > > That little trick defeats "locked" account status, an absence of a > > password and even /usr/sbin/nologin set as a default shell. > > With sudo access one can also unlock the account as well, so how is this > relevant? Of course it's relevant. The whole point of sudo is to be a controlled privilege escalation mechanism. I.e. you can grant an ordinary user A to execute a certain binaries with certain arguments as a different ordinary user B, *and* you do not have to provide an ordinary user A an access to root. Also, passwd(1): -l, --lock Note that this does not disable the account. The user may still be able to login using another authentication token (e.g. an SSH key). To disable the account, administrators should use usermod --expiredate 1 (this set the account's expire date to Jan 2, 1970). Users with a locked password are not allowed to change their password. Reco
Back to linux.debian.user | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread
Permissions on NFS mounts Paul M Foster <paulf@quillandmouse.com> - 2020-12-09 21:40 +0100
Re: Permissions on NFS mounts Dan Ritter <dsr@randomstring.org> - 2020-12-09 22:00 +0100
Re: Permissions on NFS mounts Mark Fletcher <mark27q1@gmail.com> - 2020-12-10 10:20 +0100
Re: Permissions on NFS mounts Andrei POPESCU <andreimpopescu@gmail.com> - 2020-12-10 10:50 +0100
Re: Permissions on NFS mounts Reco <recoverym4n@enotuniq.net> - 2020-12-10 11:00 +0100
Re: Permissions on NFS mounts Andrei POPESCU <andreimpopescu@gmail.com> - 2020-12-10 11:10 +0100
Re: Permissions on NFS mounts Reco <recoverym4n@enotuniq.net> - 2020-12-10 11:40 +0100
Re: Permissions on NFS mounts Andrei POPESCU <andreimpopescu@gmail.com> - 2020-12-10 14:40 +0100
Re: Permissions on NFS mounts Reco <recoverym4n@enotuniq.net> - 2020-12-10 14:50 +0100
Re: Permissions on NFS mounts David Wright <deblis@lionunicorn.co.uk> - 2020-12-10 16:40 +0100
Re: Permissions on NFS mounts Tixy <tixy@yxit.co.uk> - 2020-12-10 16:40 +0100
Re: Permissions on NFS mounts Greg Wooledge <wooledg@eeg.ccf.org> - 2020-12-10 16:50 +0100
Re: Permissions on NFS mounts Michael Stone <mstone@debian.org> - 2020-12-10 18:20 +0100
Re: Permissions on NFS mounts Michael Stone <mstone@debian.org> - 2020-12-10 18:30 +0100
Re: Permissions on NFS mounts Reco <recoverym4n@enotuniq.net> - 2020-12-10 11:00 +0100
Re: Permissions on NFS mounts Darac Marjal <mailinglist@darac.org.uk> - 2020-12-10 13:00 +0100
Re: Permissions on NFS mounts Michael Stone <mstone@debian.org> - 2020-12-10 18:00 +0100
csiph-web