Re: sudoers question
On Sat, May 13, 2023 at 09:07:19AM -0700, Kushal Kumaran wrote: [...] > The benefit is that there is no shared password. [...] Thanks. This is one very good point indeed. Cheers -- t signature.asc Description: PGP signature
Re: sudoers question
On Sat, May 13 2023 at 01:51:03 AM, Lee wrote: > On 5/12/23, DdB wrote: >> Am 13.05.2023 um 00:03 schrieb Lee: >>> On 5/12/23, Stefan Monnier wrote: > Or configure sudo to disable tty_tickets, so that the timeout (10 > minutes by default IIRC) applies to all terminals. `sudo bash` anyone? >>> >>> me! me! but I also have >> (...) >>> %adm ALL = (root) NOPASSWD: ADM_COMMANDS >> >> Of course, there are ways to allow any/all sudo commands without >> password. And i also have to cast a warning here: >> >> The kind of mistakes, any user (including yourself) can initiate, grows >> considerably, if he can use any commands without even thinking. > > In general, yes, but how much trouble can > /usr/bin/dmesg, > /usr/bin/apt list > /usr/bin/apt update > /usr/sbin/checkrestart > /usr/sbin/needrestart > cause? > > OTOH, I like the idea of logging in as root to do admin stuff. But > that seems to be frowned on now.. I don't know why :( .. unless > logging? 'sudo bash' or logging in as root doesn't leave an audit > trail of commands you've done > The benefit is that there is no shared password. If one of the people entrusted with sudo privileges needs to lose those privileges (perhaps because they leave the organization), removing that user account stops their access. If, on the other hand, you were allowing admins to login as root, you now need to change the shared root password. Of course, this requires a degree of locking down. For example, the set of users allowed to do day-to-day administration tasks must not overlap with the set of users permitted to modify the sudo configuration or set root password. You can also have different sets of users permitted to do different kinds of administrative tasks: one group might be permitted to stop/restart a small set of services, for example. And no one can be permitted to do `sudo bash` or its equivalent. Logging is a nice additional benefit, and some organizations may be required to keep audit logs for server configuration changes. sudo providing this will be a bonus for them. On single-user systems, the ability to do NOPASSWD for selected commands is nice. I don't know of any other benefit. -- regards, kushal
Re: sudoers question
to...@tuxteam.de wrote: > Security is engineering: always looking for a good tradeoff. > Not magic. > > (That's why I cringe when people around here scaremonger about > "you NEED to have a password" and things. People should know > what they are getting into, for sure, but at the same time they > should take their own decisions). Yes but -- if someone asks for advice and clearly doesn't know the tradeoffs they are making, the first advice should be to take the safer option. Pointing them at the documentation after that is good. -dsr-
Re: sudoers question
wrote: > On Sat, May 13, 2023 at 10:35:31AM +0200, Michel Verdier wrote: > > Le 12 mai 2023 tomas a écrit : > > > > >> > `sudo bash` anyone? > > >> > > >> also quicker done with > > >> su - > > > > > > But not the same. > > > > Which differences do you see ? > > For su, you have to enter the root password. For sudo, there > are many options, depending on config. Typically you enter > yours. > > Plus, you can configure which commands (and args) can be done > by whom, based on user id, local or remote, etc. > > OTOH the sudo system is way more complex than simple su, so > there's more place where bugs can hide (it has had actual > issues, btw). > > Security is engineering: always looking for a good tradeoff. > Not magic. > > (That's why I cringe when people around here scaremonger about > "you NEED to have a password" and things. People should know > what they are getting into, for sure, but at the same time they > should take their own decisions). > > Cheers Not to mention that su - uses the --login option, whilst sudo bash doesn't.
Re: sudoers question
DdB (12023-05-13): > The kind of mistakes, any user (including yourself) can initiate, grows > considerably, if he can use any commands without even thinking. You are right with this principle but you are mistaken in applying it. If you want to teach users to think before typing the password, then making sure commands that are obviously harmless do not ask for the password. There are harmless commands that for some reason require privileges. Configuring sudo to permit them without password is a good idea. Regards, -- Nicolas George signature.asc Description: PGP signature
Re: sudoers question
On Sat, May 13, 2023 at 10:35:31AM +0200, Michel Verdier wrote: > Le 12 mai 2023 tomas a écrit : > > >> > `sudo bash` anyone? > >> > >> also quicker done with > >> su - > > > > But not the same. > > Which differences do you see ? For su, you have to enter the root password. For sudo, there are many options, depending on config. Typically you enter yours. Plus, you can configure which commands (and args) can be done by whom, based on user id, local or remote, etc. OTOH the sudo system is way more complex than simple su, so there's more place where bugs can hide (it has had actual issues, btw). Security is engineering: always looking for a good tradeoff. Not magic. (That's why I cringe when people around here scaremonger about "you NEED to have a password" and things. People should know what they are getting into, for sure, but at the same time they should take their own decisions). Cheers -- t signature.asc Description: PGP signature
Re: sudoers question
Le 12 mai 2023 tomas a écrit : >> > `sudo bash` anyone? >> >> also quicker done with >> su - > > But not the same. Which differences do you see ?
Re: sudoers question
On 5/12/23, DdB wrote: > Am 13.05.2023 um 00:03 schrieb Lee: >> On 5/12/23, Stefan Monnier wrote: Or configure sudo to disable tty_tickets, so that the timeout (10 minutes by default IIRC) applies to all terminals. >>> >>> `sudo bash` anyone? >> >> me! me! but I also have > (...) >> %adm ALL = (root) NOPASSWD: ADM_COMMANDS > > Of course, there are ways to allow any/all sudo commands without > password. And i also have to cast a warning here: > > The kind of mistakes, any user (including yourself) can initiate, grows > considerably, if he can use any commands without even thinking. In general, yes, but how much trouble can /usr/bin/dmesg, /usr/bin/apt list /usr/bin/apt update /usr/sbin/checkrestart /usr/sbin/needrestart cause? OTOH, I like the idea of logging in as root to do admin stuff. But that seems to be frowned on now.. I don't know why :( .. unless logging? 'sudo bash' or logging in as root doesn't leave an audit trail of commands you've done > To my eye, as there is a huge responsability involved with using > elevated powers, i would not want "my little brother" to accidentally > sit in front of my computer while just trying commands at a console, > that he may have heard of somewhere. I gave login credentials to a 4 yr old :) I was a bit apprehensive when he started mashing the keyboard but I'd already tried to find all the world-writeable files on the machine so I wasn't all _that_ worried. I'm more concerned that I did the search wrong & missed some thing than I am of getting a "rm -fr /" from random keyboard mashing. > Even worse: When i found out, how to prevent sudo from asking a pwd, i > in fact did cause a couple of bad mistakes, that the system would > otherwise have prevented from happening (including making it > unbootable). And it took my quite some time in order to get used to some > kind of a routine, that keps me from having to reinstall everything from > scratch after each mishap. > > So, after some time, i have become way more cautious at allowing too > many powers to myself without thinking. And especially the OP did reveal > some contradictory habits: > He was asking, how to allow any sudo command without being asked for a > password ( which means: without being controlled by the system ). On one > hand, this could make sense under certain premises. > OTOH, he was failing to display any kind of responsible attitude for the > job (like as if reading logfiles was hs only interest ...). > > Just simply asking for help in this regard let me wonder, as i had been > able to find out all this without even knowing about his group, > including the relevance of sudoedit in this regard (which no one even > mentioned). > > You can't have your cake and eat it too! > > If we (as a community) would support such a behavior, wouldn't we be > responsible for the effecs, this entails No. > Would you hand out a loaded weapon to a child? (I certainly did not.) Maybe I have? But this is a personal/household machine so if files get deleted I'll get to find out if my backup/restore process works as well as I hope it does :) At work, downtime is expensive, so I do tend to lock things down at work. At home I'm a lot more casual. Regards Lee
Re: sudoers question
Am 13.05.2023 um 00:03 schrieb Lee: > On 5/12/23, Stefan Monnier wrote: >>> Or configure sudo to disable tty_tickets, so that the timeout (10 >>> minutes by default IIRC) applies to all terminals. >> >> `sudo bash` anyone? > > me! me! but I also have (...) > %adm ALL = (root) NOPASSWD: ADM_COMMANDS Of course, there are ways to allow any/all sudo commands without password. And i also have to cast a warning here: The kind of mistakes, any user (including yourself) can initiate, grows considerably, if he can use any commands without even thinking. To my eye, as there is a huge responsability involved with using elevated powers, i would not want "my little brother" to accidentally sit in front of my computer while just trying commands at a console, that he may have heard of somewhere. Even worse: When i found out, how to prevent sudo from asking a pwd, i in fact did cause a couple of bad mistakes, that the system would otherwise have prevented from happening (including making it unbootable). And it took my quite some time in order to get used to some kind of a routine, that keps me from having to reinstall everything from scratch after each mishap. So, after some time, i have become way more cautious at allowing too many powers to myself without thinking. And especially the OP did reveal some contradictory habits: He was asking, how to allow any sudo command without being asked for a password ( which means: without being controlled by the system ). On one hand, this could make sense under certain premises. OTOH, he was failing to display any kind of responsible attitude for the job (like as if reading logfiles was hs only interest ...). Just simply asking for help in this regard let me wonder, as i had been able to find out all this without even knowing about his group, including the relevance of sudoedit in this regard (which no one even mentioned). You can't have your cake and eat it too! If we (as a community) would support such a behavior, wouldn't we be responsible for the effecs, this entails? Would you hand out a loaded weapon to a child? (I certainly did not.) just saying ... good luck DdB
Re: sudoers question
On 5/12/23, Stefan Monnier wrote: >> Or configure sudo to disable tty_tickets, so that the timeout (10 >> minutes by default IIRC) applies to all terminals. > > `sudo bash` anyone? me! me! but I also have # cat /etc/sudoers.d/adm-grp-privs # members of adm can run certain commands as root without supplying # a password # Andrei POPESCU Sun, Dec 5, 2021 at 10:46 AM # To: debian-user@lists.debian.org # Re: Don't try this at home kids Cmnd_AliasADM_COMMANDS = /usr/bin/dmesg, \ /usr/bin/apt list, \ /usr/bin/apt update, \ /usr/sbin/checkrestart, \ /usr/sbin/needrestart, \ /usr/sbin/reboot %adm ALL = (root) NOPASSWD: ADM_COMMANDS Regards Lee
Re: sudoers question
On 2023-05-12, Tom Reed wrote: >> Tom Reed (12023-05-12): >>> otherwise every time i have to input password for sudo. >> >> Yes, that is the point. >> >> If “every time” is a lot for you, maybe your use habits need to be >> reviewed. >> > > that's normal. for example, I have to check every kind of logs (mail, > webserver, systems etc). They require sudo then. > > regards > > Certain people here who don't use sudo on single human user systems used to say they'd keep a root terminal open at all times (with some kind of cautionary reddish prompt to remind them of the inherent power) for convenient switching to administrative work. That's if you have no cat or child or other malicious creature in the vicinity, of course.
Re: sudoers question
On Fri, May 12, 2023 at 05:46:21PM +0200, Michel Verdier wrote: > Le 12 mai 2023 Stefan Monnier a écrit : > > >> Or configure sudo to disable tty_tickets, so that the timeout (10 > >> minutes by default IIRC) applies to all terminals. > > > > `sudo bash` anyone? > > also quicker done with > su - But not the same. Cheers -- t signature.asc Description: PGP signature
Re: sudoers question
Le 12 mai 2023 Stefan Monnier a écrit : >> Or configure sudo to disable tty_tickets, so that the timeout (10 >> minutes by default IIRC) applies to all terminals. > > `sudo bash` anyone? also quicker done with su -
Re: sudoers question
On 12/05/2023 21:00, Byung-Hee HWANG (황병희) wrote: On Fri, 2023-05-12 at 08:25 -0400, Stefan Monnier wrote: `sudo bash` anyone? AMAZING! Thanks for tip, Stefan ^^^ Isn't it a way to get e.g. ~/.bash_history owned by root? sudo -i should be better
Re: sudoers question
Hi Stefan, On Fri, 2023-05-12 at 08:25 -0400, Stefan Monnier wrote: > > Or configure sudo to disable tty_tickets, so that the timeout (10 > > minutes by default IIRC) applies to all terminals. > > `sudo bash` anyone? > AMAZING! Thanks for tip, Stefan ^^^ Sincerely, Byung-Hee -- ^고맙습니다 _布德天下_ 감사합니다_^))//
Re: sudoers question
Le 12 mai 2023 Tom Reed a écrit : > that's normal. for example, I have to check every kind of logs (mail, > webserver, systems etc). They require sudo then. Logs are with adm gid, so just add your user to the group adm to be able to consult logs.
Re: sudoers question
Stefan Monnier (12023-05-12): > `sudo bash` anyone? Why not “sudo start-gnome” or logging as root on the display manager while you are at it? Regards, -- Nicolas George
Re: sudoers question
> Or configure sudo to disable tty_tickets, so that the timeout (10 > minutes by default IIRC) applies to all terminals. `sudo bash` anyone? Stefan
Re: sudoers question
Greg Wooledge (12023-05-12): > If you're launching a terminal, running a single sudo command, closing > the terminal, opening a new terminal, etc. ... then perhaps you should > stop doing that. Leave your terminal open, at least until you're done > with whatever administrative task you're doing. Or configure sudo to disable tty_tickets, so that the timeout (10 minutes by default IIRC) applies to all terminals. Regards, -- Nicolas George
Re: sudoers question
On Fri, May 12, 2023 at 08:13:31PM +0800, Tom Reed wrote: > that's normal. for example, I have to check every kind of logs (mail, > webserver, systems etc). They require sudo then. If you check the logs all at once, as part of a daily routine, then you only have to type the password one time, at the beginning of your log-checking session. The second, third, fourth, etc. sudo commands will all use the cached credentials that you supplied the first time. You might also consider adding "tom" to the "adm" group, so that "tom" can read most of the system log files without needing sudo.
Re: sudoers question
On Fri, May 12, 2023 at 07:27:25PM +0800, Tom Reed wrote: > Hello > > what's the right way to add an user to run sudo without password? > I have to edit /etc/sudoers by manual. But I don't think it's a grace way. > > Thanks. > Tom > As others have said: sudo is *designed* this way - you have to prove your identity once and then you get some time in the session before you would have to reinput a password. If you don't appreciate why this is important, I would respectfully suggest that you go and read up on computer security. It is also worth reading up on restrictions on commands and forced commands: you can create a group such that users can only perform one command. For example, backupusers as a group and then configure sudo to *only* allow the members of that group to use a backup command. Hope this helps, Andy Cater
Re: sudoers question
Tom Reed (12023-05-12): > that's normal. for example, I have to check every kind of logs (mail, > webserver, systems etc). They require sudo then. No they do not. You just have to adjust files permissions if they are not correct by default, which they usually are. My crystal ball tells me you neglected to add yourself to the adm group. Regards, -- Nicolas George
Re: sudoers question
On Fri, May 12, 2023 at 08:03:00PM +0800, Tom Reed wrote: > for a common account, such as tom, a nopasswd sudo also makes sense? > otherwise every time i have to input password for sudo. Within a given terminal session, you only have to enter your passwors once. This will allow passwordless sudo on that terminal for the next 15 minutes (by default). If you're launching a terminal, running a single sudo command, closing the terminal, opening a new terminal, etc. ... then perhaps you should stop doing that. Leave your terminal open, at least until you're done with whatever administrative task you're doing.
Re: sudoers question
> Tom Reed (12023-05-12): >> otherwise every time i have to input password for sudo. > > Yes, that is the point. > > If “every time” is a lot for you, maybe your use habits need to be > reviewed. > that's normal. for example, I have to check every kind of logs (mail, webserver, systems etc). They require sudo then. regards
Re: sudoers question
Tom Reed (12023-05-12): > otherwise every time i have to input password for sudo. Yes, that is the point. If “every time” is a lot for you, maybe your use habits need to be reviewed. Regards, -- Nicolas George
Re: sudoers question
> On Fri, May 12, 2023 at 07:27:25PM +0800, Tom Reed wrote: >> what's the right way to add an user to run sudo without password? >> I have to edit /etc/sudoers by manual. But I don't think it's a grace >> way. > > *Without password*?? Yes, that will require a manual edit. > > There is no "graceful way" to grant that power to users, because that's > an obscene amount of power without a check. Usually one would only > do this for a non-interactive account (some sort of service/daemon > account that does an automated backup, or something of that nature). > > Hello Greg, for a common account, such as tom, a nopasswd sudo also makes sense? otherwise every time i have to input password for sudo. Thanks
Re: sudoers question
On Fri, May 12, 2023 at 07:27:25PM +0800, Tom Reed wrote: > what's the right way to add an user to run sudo without password? > I have to edit /etc/sudoers by manual. But I don't think it's a grace way. *Without password*?? Yes, that will require a manual edit. There is no "graceful way" to grant that power to users, because that's an obscene amount of power without a check. Usually one would only do this for a non-interactive account (some sort of service/daemon account that does an automated backup, or something of that nature).
sudoers question
Hello what's the right way to add an user to run sudo without password? I have to edit /etc/sudoers by manual. But I don't think it's a grace way. Thanks. Tom
Re: User is not in the sudoers file
On Mon, 2023-05-08 at 17:08 -0600, Charles Curley wrote: > On Mon, 8 May 2023 17:27:24 +0200 > wrote: > > > (2) add your user to the sudo group. I'd prefer (2). > > usermod -a -G sudo Oh Good! Thanks for tip! Sincerely, Byung-Hee -- ^고맙습니다 _布德天下_ 감사합니다_^))//
Re: User is not in the sudoers file
On Mon, 8 May 2023 19:41:35 -0400 Greg Wooledge wrote: > Wanna be lazier? Nah. I'm too lazy to edit my script. :-) -- Does anybody read signatures any more? https://charlescurley.com https://charlescurley.com/blog/
Re: User is not in the sudoers file
On Mon, May 08, 2023 at 05:08:44PM -0600, Charles Curley wrote: > On Mon, 8 May 2023 17:27:24 +0200 > wrote: > > > (2) add your user to the sudo group. I'd prefer (2). > > usermod -a -G sudo > > I'm lazy. I have that in a script. Wanna be lazier? In Debian, you can do it this way: adduser sudo
Re: User is not in the sudoers file
On Mon, 8 May 2023 17:27:24 +0200 wrote: > (2) add your user to the sudo group. I'd prefer (2). usermod -a -G sudo I'm lazy. I have that in a script. -- Does anybody read signatures any more? https://charlescurley.com https://charlescurley.com/blog/
Re: User is not in the sudoers file
On Mon, May 08, 2023 at 11:26:48AM -0400, Dan Purgert wrote: > On May 08, 2023, Igor Korot wrote: > > Hi, ALL, > > Is there a reason for the default install > > I immediately get the error in the subj? > > You likely created a root account during the initial setup. Doing that > skips over adding the first user (created during install) to sudoers > (i.e. "the operator created root, the operator will 'su root' when they > want to be root"). > > As I recall, the installer asks if you want to create root, or use sudo. Nitpick: root is always there. The question is whether it is given a password at installation or not. Cheers -- t signature.asc Description: PGP signature
Re: User is not in the sudoers file
On Mon, May 08, 2023 at 11:20:17AM -0400, Dan Ritter wrote: > Igor Korot wrote: > > Hi, ALL, > > Is there a reason for the default install > > I immediately get the error in the subj? > > > > Basically trying to run: > > > > [code] > > sudo apt-get install > > [/code] > > > Depending on the choices you made during installation, either: > > - root has a password and sudo is not installed > - root does not have a password and sudo is installed > > https://wiki.debian.org/DebianInstall > Check out "Post-Install Tips" Given the error message (see Subject), sudo seems to be installed. Cheers -- t signature.asc Description: PGP signature
Re: User is not in the sudoers file
Igor Korot wrote: > Hi, ALL, > Is there a reason for the default install > I immediately get the error in the subj? > > Basically trying to run: > > [code] > sudo apt-get install > [/code] Depending on the choices you made during installation, either: - root has a password and sudo is not installed - root does not have a password and sudo is installed https://wiki.debian.org/DebianInstall Check out "Post-Install Tips" -dsr-
Re: User is not in the sudoers file
On May 08, 2023, Igor Korot wrote: > Hi, ALL, > Is there a reason for the default install > I immediately get the error in the subj? You likely created a root account during the initial setup. Doing that skips over adding the first user (created during install) to sudoers (i.e. "the operator created root, the operator will 'su root' when they want to be root"). As I recall, the installer asks if you want to create root, or use sudo. -- |_|O|_| |_|_|O| Github: https://github.com/dpurgert |O|O|O| PGP: DDAB 23FB 19FA 7D85 1CC1 E067 6D65 70E5 4CE7 2860 signature.asc Description: PGP signature
Re: User is not in the sudoers file
On Mon, 8 May 2023 10:16:33 -0500 Igor Korot wrote: > Hi, ALL, > Is there a reason for the default install > I immediately get the error in the subj? > > Basically trying to run: > > [code] > sudo apt-get install > [/code] > > Thank you. > Sudi itself requires configuration as it does not by default allow privileges for any user. Here's the quick way in Debian: https://documentation.arcserve.com/Arcserve-UDP/Available/V6.5/ENU/Bookshelf_Files/HTML/Agent%20Online%20Help%20Linux/Content/AgentforLinuxUserGuide/udpl_config_sudo_debian.htm Here's more information about sudo, allowing much more flexibility than using the sudo group: https://wiki.archlinux.org/title/sudo The Arch Linux site is generally very useful for Debian users. -- Joe
Re: User is not in the sudoers file
On Mon, May 08, 2023 at 10:16:33AM -0500, Igor Korot wrote: > Hi, ALL, > Is there a reason for the default install > I immediately get the error in the subj? > > Basically trying to run: > > [code] > sudo apt-get install > [/code] See https://wiki.debian.org/sudo It seems you gave root a password. Now you have to become root once, the "traditional" way and either (1) edit the sudoers file to add your user, or (2) add your user to the sudo group. I'd prefer (2). Cheers -- t signature.asc Description: PGP signature
User is not in the sudoers file
Hi, ALL, Is there a reason for the default install I immediately get the error in the subj? Basically trying to run: [code] sudo apt-get install [/code] Thank you.
Re: security of debian default sudoers file (was: dead lock)
On 17/10/21 20:41, Gregor Zattler wrote: PS: in my opinion you should avoid creating a sudoers file unless you really know what you are doing. the defaults are very insecure. So force sudo to use the root passwd. After you ensure your root passwd works, simply add the line: Defaultsrootpw to /etc/sudoers. You should need a fresh terminal to test this. -- All the best Keith Bainbridge keithrbaugro...@gmail.com
security of debian default sudoers file (was: dead lock)
Hi Peter, * Peter Ehlert [2021-10-14; 06:30]: > PS: in my opinion you should avoid creating a sudoers file unless you > really know what you are doing. the defaults are very insecure. Could you please elaborate on this, or provide a pointer? Thanks; Gregor -- -... --- .-. . -.. ..--.. ...-.-
Re: [OFFTOPIC] Editing a file (was: percent char '%' in sudoers file)
On Wed, Aug 11, 2021 at 08:16:04AM -0400, Bob Bernstein wrote: > The package visudo not being installed on this system, [...] visudo is not a separate package. It's a program included in the sudo package. unicorn:~$ type visudo visudo is /usr/sbin/visudo unicorn:~$ dpkg -S /usr/sbin/visudo sudo: /usr/sbin/visudo Remember, "sudo" adds /usr/sbin to the PATH by default, so it may "see" programs that your regular user account can't see. (Unless you've changed your PATH variable, as I have.)
Re: [OFFTOPIC] Editing a file (was: percent char '%' in sudoers file)
On Tue, 10 Aug 2021, Roger Price wrote: Young Stefan had fingers so fast No filename was safe from the blast When emacs was "e" It was easy to see sud(o)ers was not meant to last This is fabulous. With two you get egg-roll, but with debian-user you get a...LIMERICK! Who knew? THANKS ALL for the spirited response to my sudo brief psychotic episode. The package visudo not being installed on this system, su, then a permission change, permitted me to remove that darned space between '%' and 'sudo' on that line in /etc/sudoers with good old jed. After restoring the original permission and exiting su, I have sudo working as expected in and out of mc. sudoedit refused even to launch after I began to monkey with various editors. It is now back at work if I need it. Excelsior -- ...a society must incorporate the rationalizing power symbolized by scientific knowledge, for otherwise it will be a fatally split society- split between a powerful elite and the disenfranchised mass. To this we add now: an irrational elite is the most dangerous of all. Holton, Gerald. 1985. On the Integrity of Science: The Issues Since Bronowski. Leonardo 18 (4), Special Issue: Jacob Bronowski: A Retrospective (1985): 229-232.
[OFFTOPIC] Editing a file (was: percent char '%' in sudoers file)
Roger Price [2021-08-10 11:11:24] wrote: > On Tue, 10 Aug 2021, Bob Bernstein wrote: >> Full disclosure: In a typical Bob fit of impulsivity I, yes, edited this >> file using 'sudo nsno /etc/sudoers'. > My impulse would be to use VISUAL=/usr/bin/emacs visudo -f /etc/sudoers You guys have amazing impulse control. My fingers would have typed `e /etc/suders` before I would have had a chance to do anything about it. Stefan PS: Of course the `e` above stands for Emacs, tho my root user has it redirected to Zile.
Re: [OFFTOPIC] Editing a file (was: percent char '%' in sudoers file)
On Tue, 10 Aug 2021, Stefan Monnier wrote: Roger Price [2021-08-10 11:11:24] wrote: On Tue, 10 Aug 2021, Bob Bernstein wrote: Full disclosure: In a typical Bob fit of impulsivity I, yes, edited this file using 'sudo nsno /etc/sudoers'. My impulse would be to use VISUAL=/usr/bin/emacs visudo -f /etc/sudoers You guys have amazing impulse control. My fingers would have typed `e /etc/suders` before I would have had a chance to do anything about it. Young Stefan had fingers so fast No filename was safe from the blast When emacs was "e" It was easy to see sud(o)ers was not meant to last
Re: percent char '%' in sudoers file
On 2021-08-10 07:19, Bob Bernstein wrote: My copy (buster amd64) of lines 23-24 of /etc/sudoers looks like this: 23 # Allow members of group sudo to execute any comm$ 24 % sudo ALL=(ALL:ALL) ALL Is that '%' a comment char? The line numbers shown were provided by nano. I know, I know, please keep reading. I assumed also, partly because I didn't have my glasses, that "%" was a comment and deleted that line in ssh config or something on synology NAS. Then I twigged "%" was group, but that's how we learn. mick -- Key ID4BFEBB31
Re: percent char '%' in sudoers file
On 8/10/2021 1:11 PM, Greg Wooledge wrote: On Tue, Aug 10, 2021 at 09:13:22AM +0200, john doe wrote: Fulling around is the best way to learn if you can take the time to fix the issue(s) that your impulsivity has caused!!! :) (Fooling around.) If you do choose to fool around with sudoers, please keep a root shell open at all times. Don't cut yourself off from root by counting on being able to do "sudo nano /etc/sudoers" again, because you might have broken sudo. "sudo -s" gives you a shell as root. Even if you never have to run a single command in that shell, having it there for emergency use is wise. Obviously, fooling around should not be done on a production server/something that you need to have stable. As long as you are messing around with sudo, that might not be a bad idea to configure 'su' as a fallback mechanism. -- John Doe
Re: percent char '%' in sudoers file
On Tue, Aug 10, 2021 at 07:11:55AM -0400, Greg Wooledge wrote: > On Tue, Aug 10, 2021 at 09:13:22AM +0200, john doe wrote: > > Fulling around is the best way to learn if you can take the time to fix > > the issue(s) that your impulsivity has caused!!! :) > > (Fooling around.) If you do choose to fool around with sudoers, please > keep a root shell open at all times. Don't cut yourself off from root > by counting on being able to do "sudo nano /etc/sudoers" again, because > you might have broken sudo. ...or learn how to access your "dead" disk without booting from it (live system, rescue, extracting the disk and mounting it on other system -- choices are... panoramic here; most of the time you'll need some extra hardware, a prepared, lowly USB stick might suffice :-) > "sudo -s" gives you a shell as root. Even if you never have to run a > single command in that shell, having it there for emergency use is wise. ...but I do agree that Greg's advice potentially leads to the shortest downtimes :-D Cheers - t signature.asc Description: Digital signature
Re: percent char '%' in sudoers file
Greg Wooledge (12021-08-10): > (Fooling around.) If you do choose to fool around with sudoers, please > keep a root shell open at all times. Don't cut yourself off from root > by counting on being able to do "sudo nano /etc/sudoers" again, because > you might have broken sudo. Also, use visudo instead of editing the file directly, it will at least check the syntax before letting you overwrite it. signature.asc Description: PGP signature
Re: percent char '%' in sudoers file
On Tue, Aug 10, 2021 at 09:13:22AM +0200, john doe wrote: > Fulling around is the best way to learn if you can take the time to fix > the issue(s) that your impulsivity has caused!!! :) (Fooling around.) If you do choose to fool around with sudoers, please keep a root shell open at all times. Don't cut yourself off from root by counting on being able to do "sudo nano /etc/sudoers" again, because you might have broken sudo. "sudo -s" gives you a shell as root. Even if you never have to run a single command in that shell, having it there for emergency use is wise.
Re: percent char '%' in sudoers file
On Tue, Aug 10, 2021 at 11:11:24AM +0200, Roger Price wrote: My impulse would be to use VISUAL=/usr/bin/emacs visudo -f /etc/sudoers (for the OP:) the tool "visudo" is a wrapper around an editor (despite its name, the editor does not have to be vi, as Roger demonstrates here) that launches your preferred editor (one way to specify that is by defining it in the VISUAL environment variable, as here) editing /etc/sudoers. But when you quit the editor, visudo sanity checks the resulting file before copying it into place. It's a useful safety check to prevent you accidentally breaking the sudoers file and locking yourself out of gaining superuser on your machine. -- Please do not CC me for listmail. 👱🏻 Jonathan Dowland ✎j...@debian.org 🔗 https://jmtd.net
Re: percent char '%' in sudoers file
On Tue, 10 Aug 2021, Bob Bernstein wrote: Full disclosure: In a typical Bob fit of impulsivity I, yes, edited this file using 'sudo nsno /etc/sudoers'. My impulse would be to use VISUAL=/usr/bin/emacs visudo -f /etc/sudoers Roger
Re: percent char '%' in sudoers file
Bob Bernstein writes: > Full disclosure: In a typical Bob fit of impulsivity I, yes, edited > this file using 'sudo nsno /etc/sudoers'. In general, consider making a backup of config files before editing. Here's a sudo mini course: - Consider what needs to run as root and only run that command with sudo. - To edit a file: sudoedit file - Sometimes it's just easier to to run a shell as root: sudo -s For documentation: - man sudo - man sudoers > Alright, enough fooling around. I am a great fan of Dr. John > E. Davis's (the author of jed) viewer app 'most.' I cannot seem to > persuade mc to honor my env var VIEWER which asks for 'most.' Wow, I didn't know most is still around. I remember using it a long time ago but I've stuck with less. I guess mostly because it's a lot more likely to be available than most as I use Linux systems that I don't manage myself as well... Anyways, the mc manual says mc uses the builtin viewer unless "Use internal view" option is disabled, otherwise it uses PAGER or VIEWER. Seems to work for me for both less and most.
Re: percent char '%' in sudoers file
On Tue, 10 Aug 2021 08:57:46 +0200 wrote: > What I'm not sure is whether the whitespace between the '%' and > the 'sudo' is relevant. My /etc/sudoers hasn't that. Mine is the same - no space = %sudo ALL=(ALL:ALL) ALL Best Keith Bainbridge keithrbaugro...@gmail.com
Re: percent char '%' in sudoers file
On 8/10/2021 8:19 AM, Bob Bernstein wrote:
My copy (buster amd64) of lines 23-24 of /etc/sudoers looks like this:
I would suggest to use the directory '/etc/sudoers.d' instead of
modifying the 'sudoers' file.
23 # Allow members of group sudo to execute any comm$
24 % sudo ALL=(ALL:ALL) ALL
Is that '%' a comment char? The line numbers shown were provided by
No, '%' tells that 'sudo' is a group.
nano. I know, I know, please keep reading.
Full disclosure: In a typical Bob fit of impulsivity I, yes, edited this
file using 'sudo nsno /etc/sudoers'. How much damage have I done, what
are the penalties for such behaviour, and will I get time off for good
behaviour?
Fulling around is the best way to learn if you can take the time to fix
the issue(s) that your impulsivity has caused!!! :)
Alright, enough fooling around. I am a great fan of Dr. John E. Davis's
(the author of jed) viewer app 'most.' I cannot seem to persuade mc to
honor my env var VIEWER which asks for 'most.'
I am new to using sudo. All suggestions bearing even the slightest hint
of civility will be thoughtfully considered.
Space separating the '%' and the group name ('sudo') does not strike me
as a good idea.
--
John Doe
Re: percent char '%' in sudoers file
On Tue, 10 Aug 2021 at 16:58, wrote: > On Tue, Aug 10, 2021 at 02:19:18AM -0400, Bob Bernstein wrote: > > My copy (buster amd64) of lines 23-24 of /etc/sudoers looks like > > this: > > 23 # Allow members of group sudo to execute any comm$ > > 24 % sudo ALL=(ALL:ALL) ALL > > > > Is that '%' a comment char? > No. It is a group indicator. It means that users who are members > of the group 'sudo' are allowed to runn ALL commands as any (ALL) > user and any (ALL) group, but they have to authenticate (NOPASSW > is missing). > What I'm not sure is whether the whitespace between the '%' and > the 'sudo' is relevant. My /etc/sudoers hasn't that. 'man 5 sudoers' format specification shows no space between the '%' and the group name. By that guidance, it looks wrong and I would remove it.
Re: percent char '%' in sudoers file
On Tue, Aug 10, 2021 at 02:19:18AM -0400, Bob Bernstein wrote: > My copy (buster amd64) of lines 23-24 of /etc/sudoers looks like > this: > > 23 # Allow members of group sudo to execute any comm$ > 24 % sudo ALL=(ALL:ALL) ALL > > Is that '%' a comment char? No. It is a group indicator. It means that users who are members of the group 'sudo' are allowed to runn ALL commands as any (ALL) user and any (ALL) group, but they have to authenticate (NOPASSW is missing). What I'm not sure is whether the whitespace between the '%' and the 'sudo' is relevant. My /etc/sudoers hasn't that. > The line numbers shown were provided by > nano. I know, I know, please keep reading. > > Full disclosure: In a typical Bob fit of impulsivity I, yes, edited > this file using 'sudo nsno /etc/sudoers'. How much damage have I > done, what are the penalties for such behaviour, and will I get time > off for good behaviour? I don't talk nano. Spanish, German, French and some English, that's enough for my little brain ;-) Cheers - t signature.asc Description: Digital signature
percent char '%' in sudoers file
My copy (buster amd64) of lines 23-24 of /etc/sudoers looks like this: 23 # Allow members of group sudo to execute any comm$ 24 % sudo ALL=(ALL:ALL) ALL Is that '%' a comment char? The line numbers shown were provided by nano. I know, I know, please keep reading. Full disclosure: In a typical Bob fit of impulsivity I, yes, edited this file using 'sudo nsno /etc/sudoers'. How much damage have I done, what are the penalties for such behaviour, and will I get time off for good behaviour? Alright, enough fooling around. I am a great fan of Dr. John E. Davis's (the author of jed) viewer app 'most.' I cannot seem to persuade mc to honor my env var VIEWER which asks for 'most.' I am new to using sudo. All suggestions bearing even the slightest hint of civility will be thoughtfully considered. Thank you. -- ...a society must incorporate the rationalizing power symbolized by scientific knowledge, for otherwise it will be a fatally split society- split between a powerful elite and the disenfranchised mass. To this we add now: an irrational elite is the most dangerous of all. Holton, Gerald. 1985. On the Integrity of Science: The Issues Since Bronowski. Leonardo 18 (4), Special Issue: Jacob Bronowski: A Retrospective (1985): 229-232.
Re: sudo does not respond to settings in /etc/sudoers
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2015-11-16 19:02, Andreas Henriksson wrote: > For what it's worth, if you want to avoid logging out/in you can > temporarily join the group in your shell by using "newgrp sudo". Thank you for that tip; it is useful to know. Ken -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iEYEARECAAYFAlZJ6QYACgkQlNlJzOkJmTd7XQCfVkYMZawUyHDxy7A/O96OYmaF SfIAmwTd50WNppet3r1P9DknHJtILdGv =JG+B -END PGP SIGNATURE-
Re: sudo does not respond to settings in /etc/sudoers
Ken Heard [2015-11-16 13:50:09+07] wrote: > On 2015-11-15 23:26, Teemu Likonen wrote: >> Maybe you added the user to the "undo" group > > Surely you mean the "sudo" group? Yes, of course. :-) signature.asc Description: PGP signature
Re: sudo does not respond to settings in /etc/sudoers
Hello! On Mon, Nov 16, 2015 at 01:50:09PM +0700, Ken Heard wrote: [...] > My eureka moment! I forgot to logout and in again as my user before > testing the various options. [...] For what it's worth, if you want to avoid logging out/in you can temporarily join the group in your shell by using "newgrp sudo". Regards, Andreas Henriksson
Re: sudo does not respond to settings in /etc/sudoers
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 2015-11-15 23:26, Teemu Likonen wrote: > Maybe you added the user to the "undo" group Surely you mean the "sudo" group? > but forgot to test it with a new login session. Group changes > don't affect the current login session (unless newgrp is used). My eureka moment! I forgot to logout and in again as my user before testing the various options. I tested the two options to do what I wanted to do as described in my original post, but not both on, or open at the same time. I found that adding to the "user privilege specification" section in the sudoers file the following line DOES work: ken ALL=NOPASSWD: ALL However, removing that line, and in the TDE User Manager (Kuser) simply adding my user to the "sudo" group does NOT work. That option DOES nevertheless work in my Jessie box. Strange. Thanks guys for collectively putting me on the right track. Ken -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iEYEARECAAYFAlZJfKEACgkQlNlJzOkJmTfY6ACeOijk3QTayP+2rIpUJ0N9Zj2x sSYAn01UPKZyBd6QAa1t0GbcT+9d7hF3 =hCiX -END PGP SIGNATURE-
Re: sudo does not respond to settings in /etc/sudoers
Did you check the permissions? -r--r- 1 root root 1011 Oct 4 21:58 /etc/sudoers On Sun, Nov 15, 2015 at 5:27 PM, Ric Moore wrote: > On 11/15/2015 11:18 AM, Joe wrote: > >> On Sun, 15 Nov 2015 10:44:10 -0500 >> Ric Moore wrote: >> >> On 11/14/2015 03:01 PM, Joe wrote: >>> Your example will >>> >>>> still ask for a password, and anyway it's either/or: you can either >>>> add yourself to the sudo group or add your name to sudoers, you >>>> don't need both. >>>> >>> >>> I had to, before it would work. YMMV, Ric >>> >>> >>> >> You must have an unusually paranoid computer. I have a sid workstation >> and wheezy server running at the moment, neither of which has any >> members of the sudo group, which I think is a relatively recent >> innovation in Debian. >> >> It might be one of those situations where 'I did A and it didn't work, >> I did B and it didn't work, I did C and it finally did work, and I was >> so relieved that I could get on with the job that was being held up that >> I didn't take the time to go back and undo A and B'. We've all been >> there, and have bits of mostly harmless cruft here and there to prove >> it... >> > > I just installed fresh, after a stinkin' seagate drive failed miserably, > and had to do both steps before sudo would work. It's become automatic to > do A and B to get C. But then again, I've never reversed the process to see > if A or B could be omitted. Maybe I'm scared. Ric > > > > -- > My father, Victor Moore (Vic) used to say: > "There are two Great Sins in the world... > ..the Sin of Ignorance, and the Sin of Stupidity. > Only the former may be overcome." R.I.P. Dad. > http://linuxcounter.net/user/44256.html > >
Re: sudo does not respond to settings in /etc/sudoers
On 11/15/2015 11:18 AM, Joe wrote: On Sun, 15 Nov 2015 10:44:10 -0500 Ric Moore wrote: On 11/14/2015 03:01 PM, Joe wrote: Your example will still ask for a password, and anyway it's either/or: you can either add yourself to the sudo group or add your name to sudoers, you don't need both. I had to, before it would work. YMMV, Ric You must have an unusually paranoid computer. I have a sid workstation and wheezy server running at the moment, neither of which has any members of the sudo group, which I think is a relatively recent innovation in Debian. It might be one of those situations where 'I did A and it didn't work, I did B and it didn't work, I did C and it finally did work, and I was so relieved that I could get on with the job that was being held up that I didn't take the time to go back and undo A and B'. We've all been there, and have bits of mostly harmless cruft here and there to prove it... I just installed fresh, after a stinkin' seagate drive failed miserably, and had to do both steps before sudo would work. It's become automatic to do A and B to get C. But then again, I've never reversed the process to see if A or B could be omitted. Maybe I'm scared. Ric -- My father, Victor Moore (Vic) used to say: "There are two Great Sins in the world... ..the Sin of Ignorance, and the Sin of Stupidity. Only the former may be overcome." R.I.P. Dad. http://linuxcounter.net/user/44256.html
Re: sudo does not respond to settings in /etc/sudoers
Ric Moore [2015-11-15 10:44:10-05] wrote: > On 11/14/2015 03:01 PM, Joe wrote: >> it's either/or: you can either add yourself to the sudo group or add >> your name to sudoers, you don't need both. > > I had to, before it would work. YMMV, Ric Maybe you added the user to the "undo" group but forgot to test it with a new login session. Group changes don't affect the current login session (unless newgrp is used). signature.asc Description: PGP signature
Re: sudo does not respond to settings in /etc/sudoers
On Sun, 15 Nov 2015 10:44:10 -0500 Ric Moore wrote: > On 11/14/2015 03:01 PM, Joe wrote: > Your example will > > still ask for a password, and anyway it's either/or: you can either > > add yourself to the sudo group or add your name to sudoers, you > > don't need both. > > I had to, before it would work. YMMV, Ric > > You must have an unusually paranoid computer. I have a sid workstation and wheezy server running at the moment, neither of which has any members of the sudo group, which I think is a relatively recent innovation in Debian. It might be one of those situations where 'I did A and it didn't work, I did B and it didn't work, I did C and it finally did work, and I was so relieved that I could get on with the job that was being held up that I didn't take the time to go back and undo A and B'. We've all been there, and have bits of mostly harmless cruft here and there to prove it... -- Joe
Re: sudo does not respond to settings in /etc/sudoers
On 11/14/2015 03:01 PM, Joe wrote: Your example will still ask for a password, and anyway it's either/or: you can either add yourself to the sudo group or add your name to sudoers, you don't need both. I had to, before it would work. YMMV, Ric -- My father, Victor Moore (Vic) used to say: "There are two Great Sins in the world... ..the Sin of Ignorance, and the Sin of Stupidity. Only the former may be overcome." R.I.P. Dad. http://linuxcounter.net/user/44256.html
Re: sudo does not respond to settings in /etc/sudoers
Ken Heard [2015-11-14 15:11:05+07] wrote: > In my Wheezy box I want to be able to run any root command as my user > without having to enter a password to do so. > # ken ALL=NOPASSWD: ALL How about this: ken ALL = (root) NOPASSWD: ALL Works here but this is Debian 8 (Jessie), not Wheezy. signature.asc Description: PGP signature
Re: sudo does not respond to settings in /etc/sudoers
On Sat, 14 Nov 2015 13:20:19 -0500 Ric Moore wrote: > On 11/14/2015 09:36 AM, Mario Castelán Castro wrote: > > El 14/11/15 a las 02:11, Ken Heard escribió: > >> -BEGIN PGP SIGNED MESSAGE- > >> Hash: SHA1 > >> > >> In my Wheezy box I want to be able to run any root command as my > >> user without having to enter a password to do so. I assume that > >> there are two ways to do so: either make my user a member of the > >> sudo group, or add a line to sudoers giving such privileges to my > >> user. Neither worked. > > > > You have to add the "NOPASSWD" option. Check the "sudoers" man > > page. > > Add your user to the sudo group like this in /etc/group : > sudo:x:27:ric > ...using your own user name. Then it will work, if you added your > user to /ect/sudoers like: > # User privilege specification > root ALL=(ALL:ALL) ALL > ric ALL=(ALL:ALL) ALL > > > ...works for me(tm) :)Ric > > > The OP did explicitly say he wanted to use the NOPASSWD option, and his sudoers file shows it in use, currently commented. Your example will still ask for a password, and anyway it's either/or: you can either add yourself to the sudo group or add your name to sudoers, you don't need both. The sudo group is just a quick and simple way of giving the same set of [presumably low-level] privileges to a number of people, and the sudo sudoers entry really shouldn't be NOPASSWD, as by default it gives full root privileges. I don't use NOPASSWD myself, so I can't give a definitive answer (as in 'this works for me') to the question, but presumably there's a semantic issue somewhere. Visudo can only pick up syntax errors, it can't tell what you meant to achieve. -- Joe
Re: sudo does not respond to settings in /etc/sudoers
On 11/14/2015 09:36 AM, Mario Castelán Castro wrote: El 14/11/15 a las 02:11, Ken Heard escribió: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 In my Wheezy box I want to be able to run any root command as my user without having to enter a password to do so. I assume that there are two ways to do so: either make my user a member of the sudo group, or add a line to sudoers giving such privileges to my user. Neither worked. You have to add the "NOPASSWD" option. Check the "sudoers" man page. Add your user to the sudo group like this in /etc/group : sudo:x:27:ric ...using your own user name. Then it will work, if you added your user to /ect/sudoers like: # User privilege specification rootALL=(ALL:ALL) ALL ric ALL=(ALL:ALL) ALL ...works for me(tm) :)Ric -- My father, Victor Moore (Vic) used to say: "There are two Great Sins in the world... ..the Sin of Ignorance, and the Sin of Stupidity. Only the former may be overcome." R.I.P. Dad. http://linuxcounter.net/user/44256.html
Re: sudo does not respond to settings in /etc/sudoers
El 14/11/15 a las 02:11, Ken Heard escribió: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 In my Wheezy box I want to be able to run any root command as my user without having to enter a password to do so. I assume that there are two ways to do so: either make my user a member of the sudo group, or add a line to sudoers giving such privileges to my user. Neither worked. You have to add the "NOPASSWD" option. Check the "sudoers" man page.
sudo does not respond to settings in /etc/sudoers
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 In my Wheezy box I want to be able to run any root command as my user without having to enter a password to do so. I assume that there are two ways to do so: either make my user a member of the sudo group, or add a line to sudoers giving such privileges to my user. Neither worked. My sudoers file reads as follows: # # This file MUST be edited with the 'visudo' command as root. # # Please consider adding local content in /etc/sudoers.d/ instead of # directly modifying this file. # # See the man page for details on how to write a sudoers file. # Defaultsenv_reset Defaultsmail_badpass Defaults secure_path="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin" # Host alias specification # User alias specification # Cmnd alias specification # User privilege specification rootALL=(ALL:ALL) ALL # ken ALL=NOPASSWD: ALL # martinAll=(ALL:ALL) ALL # Allow members of group sudo to execute any command %sudo ALL=(ALL:ALL) ALL # See sudoers(5) for more information on "#include" directives: #includedir /etc/sudoers.d I first entered the line under "user privilege specification" beginning with "ken" -- without the "#" of course -- it did not work. Next I commented out that line and added to the sudo group "ken" my user. That did not work either. The command "visudo -c" returns the following: /etc/sudoers: parsed OK /etc/sudoers.d/README: parsed OK /etc/sudoers.d/tde-secure-path: parsed OK Strangely enough I have the same sudoers file in another computer using Jessie. On that computer both the options I tried for the wheezy computer worked. Is this a bug for the Wheezy computer, or is there something I did not do or did wrong to prevent me from achieving the result I desired? Regards, Ken -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.12 (GNU/Linux) iEYEARECAAYFAlZG7JkACgkQlNlJzOkJmTd6LACeMoTBd6V5VLmOMfsyg3p1DuXI rxEAnRfp5FdfLZwxiNB4fZHYi9MMxJx1 =PwCP -END PGP SIGNATURE-
Re: /etc/environment not available for normal user while for root it is[was Re: sudo not respecting /etc/sudoers]
On Sun, May 3, 2015, at 11:56, Avinash Sonawane wrote: > On Sun, May 3, 2015 at 8:24 PM, Avinash Sonawane > wrote: > > On Sun, May 3, 2015 at 7:58 PM, Nicolas George wrote: > >> Le quartidi 14 floréal, an CCXXIII, Avinash Sonawane a écrit : > >>> So will it work if I add `authrequiredpam_env.so` > >>> to lightdm, lightdm-greeter and lightdm-autologin files? > >> > >> Try. > > > > Awesome! It worked! I added `authrequired > > pam_env.so` in lightdm, lightdm-greeter and lightdm-autologin just > > above the line `auth required pam_env.so > > envfile=/etc/default/locale` > > By the way there are no security related adversaries to this right? I assume you mean "security advisories". There are none related to this at the moment, AFAIK. Do note that /etc/default/locale and /etc/environment, as well as the /etc and /etc/default directories must be restricted so that only root can modify them. But that's nothing new, and Debian will have set it up properly by default, so unless something else messed with them... -- "One disk to rule them all, One disk to find them. One disk to bring them all and in the darkness grind them. In the Land of Redmond where the shadows lie." -- The Silicon Valley Tarot Henrique de Moraes Holschuh -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1431345890.1266387.265522689.5c04d...@webmail.messagingengine.com
Re: sudo not respecting /etc/sudoers
On Sun, May 03, 2015 at 03:20:05PM +0200, Nicolas George wrote: > Le quartidi 14 floréal, an CCXXIII, Jonathan Dowland a écrit : > > There's nothing wrong with the file permissions. By default, root's > > shell reads /etc/environment, but users do not. To be honest I'm not > > sure why that is the case. > > I believe you are wrong. I tested my hypothesis before I wrote to the list. May I ask that do the same before you share your opinion? > > You can configure your user(s) to source /etc/environment by adding '. > > /etc/environment' to their ~/.bashrc files (assuming they still use bash). > > This is bugware. /etc/environment is read by PAM. If it is not, then the PAM > configuration is faulty. As far as I can see, pam_env.so is invoked by each > specific PAM configuration; IMHO, it should be in common-session. Aha! By default, indeed it is. So *Login* shells will get it sourced, but others will not. My testing was limited to sub-shells of my tmux session, which are not login shells. Indeed I rarely launch a new login shell on this particular box, and so, without modifications such as I have suggested, I or anyone operating in a similar fashion to me would not pick up changes to /etc/environment very often. > > (IMHO that's preferable to whitelisting the http_proxy env variable). > > It may be the case if sudo was used to grant LIMITED access to the user. > When granting UNLIMITED access, whitelisting the environment variable is > preferable. I addressed this in my other reply. Thanks, -- Jonathan Dowland -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150504202824.gb31...@chew.redmars.org
Re: sudo not respecting /etc/sudoers
Hi, Please do not CC me, I am subscribed to the list. On Sun, May 03, 2015 at 03:36:10PM +0200, Nicolas George wrote: > Le quartidi 14 floréal, an CCXXIII, Jonathan Dowland a écrit : > > This is inevitable with http_proxy, sadly, as there is no one place you can > > put things that will guarantee that all processes with get them as > > environment variables, and no guarantee that all processes will honour > > http_proxy anyway. > > This is true, but completely irrelevant in this case because the discussion > is not about ALL processes, it is about this particular instance of the > user's shell and apt-get. I don't believe it's irrelevant. My ambition in offering advice on the list is to offer practical advice. If it's a hopeless task to define the http proxy in just one place, then it's relavant IMHO to suggest it foolhardy to pursue that end. > > There are drawbacks to doing it. With -E it's potentially passing dangerous > > environment variables up to the super process. With whitelisting the > > http_proxy you're exposing yourself to attacks where a malicious > > person/process/whatever can point apt (or other things) at a malicious > > http_proxy. > > Once again, this is true but irrelevant for this discussion. Security is always relevant IMHO. We don't know enough of OP's environment to asses the risk. A safe answer is a more generally useful answer. > Sanitizing the environment against possible dangerous values is necessary > when granting LIMITED privileges with sudo, i.e. allowing to run only some > specific commands with elevated privileges. > > When granting UNLIMITED privileges, i.e. allowing to run any command with > sudo, sanitizing the environment is just a matter of convenience. We don't know whether the user shares the box, has other users who are limited, who would also be affected by the introduction of env_var in sudoers, nor about anyone else reading, copying or adapting the answer for their own purposes. > And when the address of the proxy will change, they will have a hard > figuring out what is wrong with apt-get. That is one of the drawback of your > proposed solution. That's a good point, apt does not provide adequate diagnostic output when the proxy server cannot be reached or does not respond. This is a bug that should be reported, if it hasn't already. This is the same whether you use -o or not, though. I agree that it's probably going to be more obvious if you've hand-typed the address at the time of the failure. > The major drawback, of course, is that you are suggesting a fix without > having understood the problem first. This is a very bad habit. I don't know quite how you have come to that conclusion, but regardless of what you think, this seems needlessly rude. Please try to be civil. -- Jonathan Dowland -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150504202241.ga31...@chew.redmars.org
Re: /etc/environment not available for normal user while for root it is[was Re: sudo not respecting /etc/sudoers]
On Sun, May 3, 2015 at 8:24 PM, Avinash Sonawane wrote: > On Sun, May 3, 2015 at 7:58 PM, Nicolas George wrote: >> Le quartidi 14 floréal, an CCXXIII, Avinash Sonawane a écrit : >>> So will it work if I add `authrequiredpam_env.so` >>> to lightdm, lightdm-greeter and lightdm-autologin files? >> >> Try. > > Awesome! It worked! I added `authrequired > pam_env.so` in lightdm, lightdm-greeter and lightdm-autologin just > above the line `auth required pam_env.so > envfile=/etc/default/locale` By the way there are no security related adversaries to this right? -- Avinash Sonawane (RootKea) PICT, Pune http://www.rootkea.wordpress.com -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CAJ9BSW_9Ymg00BR8q+aoWgQTCg_=Uom1Rujk=5skFAH=dql...@mail.gmail.com
Re: /etc/environment not available for normal user while for root it is[was Re: sudo not respecting /etc/sudoers]
On Sun, May 3, 2015 at 7:58 PM, Nicolas George wrote: > Le quartidi 14 floréal, an CCXXIII, Avinash Sonawane a écrit : >> So will it work if I add `authrequiredpam_env.so` >> to lightdm, lightdm-greeter and lightdm-autologin files? > > Try. Awesome! It worked! I added `authrequired pam_env.so` in lightdm, lightdm-greeter and lightdm-autologin just above the line `auth required pam_env.so envfile=/etc/default/locale` and now /etc/environment is available for normal user. Thank you so much! -- Avinash Sonawane (RootKea) PICT, Pune http://rootkea.wordpress.com -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CAJ9BSW9wXFwCjCFDwGFprCJkNjMpv-nHPxFo6J1c=ezsaa6...@mail.gmail.com
Re: /etc/environment not available for normal user while for root it is[was Re: sudo not respecting /etc/sudoers]
Le quartidi 14 floréal, an CCXXIII, Avinash Sonawane a écrit : > So will it work if I add `authrequiredpam_env.so` > to lightdm, lightdm-greeter and lightdm-autologin files? Try. > So I should file this against jessie, lightdm or xfce(as in GNOME > /etc/environment was getting loaded as expected)? Against the package that provides the faulty configuration file. > Also as suggested in previous thread I added these lines in .bashrc: > . /etc/environment > export http_proxy https_proxy ftp_proxy > > and the workaround works! > > Is there any risk in using this workaround? Yes, several. The configuration will not apply to some situations where it should apply, and it will apply to some situations where it should not. Regards, -- Nicolas George signature.asc Description: Digital signature
Re: /etc/environment not available for normal user while for root it is[was Re: sudo not respecting /etc/sudoers]
On Sun, May 3, 2015 at 7:15 PM, Nicolas George wrote: > Le quartidi 14 floréal, an CCXXIII, Avinash Sonawane a écrit : >> I think I am using lightdm as display manager/login manager. (Any way >> to find out which is?) > > You can probably see what display manager is running with "ps". Yes. It is lightdm. > >> And in lightdm, lightdm-autologin and lightdm-greeter I see: >> >> # Load environment from /etc/environment and ~/.pam_environment >> auth required pam_env.so envfile=/etc/default/locale >> >> > If there is, check that pam_env.so is invoked. >> >> Apparently pam_env.so is alreadu being invoked. > > Not exactly. It is invoked to read /etc/default/locale, but not > /etc/environment. The correct lines, from xdm, look like this: > > authrequiredpam_env.so > authrequiredpam_env.so envfile=/etc/default/locale > > See there are two lines. The behaviour contradicts the comment just above: So will it work if I add `authrequiredpam_env.so` to lightdm, lightdm-greeter and lightdm-autologin files? > there is not doubt this is a bug. You must file a bug report. So I should file this against jessie, lightdm or xfce(as in GNOME /etc/environment was getting loaded as expected)? Also as suggested in previous thread I added these lines in .bashrc: . /etc/environment export http_proxy https_proxy ftp_proxy and the workaround works! Is there any risk in using this workaround? -- Avinash Sonawane (RootKea) PICT, Pune http://www.rootkea.wordpress.com -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CAJ9BSW9ngyZxtC7iYwsQDj7zg-9YZVPeRrBBAyKd-=txpnu...@mail.gmail.com
Re: /etc/environment not available for normal user while for root it is[was Re: sudo not respecting /etc/sudoers]
Le quartidi 14 floréal, an CCXXIII, Avinash Sonawane a écrit : > I think I am using lightdm as display manager/login manager. (Any way > to find out which is?) You can probably see what display manager is running with "ps". > And in lightdm, lightdm-autologin and lightdm-greeter I see: > > # Load environment from /etc/environment and ~/.pam_environment > auth required pam_env.so envfile=/etc/default/locale > > > If there is, check that pam_env.so is invoked. > > Apparently pam_env.so is alreadu being invoked. Not exactly. It is invoked to read /etc/default/locale, but not /etc/environment. The correct lines, from xdm, look like this: authrequiredpam_env.so authrequiredpam_env.so envfile=/etc/default/locale See there are two lines. The behaviour contradicts the comment just above: there is not doubt this is a bug. You must file a bug report. Regards, -- Nicolas George signature.asc Description: Digital signature
Re: /etc/environment not available for normal user while for root it is[was Re: sudo not respecting /etc/sudoers]
On Sun, May 3, 2015 at 6:51 PM, Nicolas George wrote: > Le quartidi 14 floréal, an CCXXIII, Avinash Sonawane a écrit : >> I am using Jessie with XFCE. > > Look in /etc/pam.d/ if there is a file related to xfce and its display > manager. $ ls /etc/pam.d -rw-r--r-- 1 root root 235 Sep 30 2014 atd -rw-r--r-- 1 root root 384 Nov 20 02:11 chfn -rw-r--r-- 1 root root92 Nov 20 02:11 chpasswd -rw-r--r-- 1 root root 581 Nov 20 02:11 chsh -rw-r--r-- 1 root root 1208 May 2 19:24 common-account -rw-r--r-- 1 root root 1221 May 2 19:24 common-auth -rw-r--r-- 1 root root 1480 May 2 19:24 common-password -rw-r--r-- 1 root root 1189 May 2 19:24 common-session -rw-r--r-- 1 root root 1154 May 2 19:24 common-session-noninteractive -rw-r--r-- 1 root root 606 Oct 26 2014 cron -rw-r--r-- 1 root root69 Sep 17 2014 cups -rw-r--r-- 1 root root 1298 Nov 5 02:31 lightdm -rw-r--r-- 1 root root 1308 Nov 5 02:31 lightdm-autologin -rw-r--r-- 1 root root 437 Nov 5 02:31 lightdm-greeter -rw-r--r-- 1 root root 4756 Nov 20 02:18 login -rw-r--r-- 1 root root92 Nov 20 02:11 newusers -rw-r--r-- 1 root root 520 Aug 9 2014 other -rw-r--r-- 1 root root92 Nov 20 02:11 passwd -rw-r--r-- 1 root root 255 Nov 28 14:39 polkit-1 -rw-r--r-- 1 root root 168 Sep 20 2014 ppp -rw-r--r-- 1 root root 143 Mar 30 03:59 runuser -rw-r--r-- 1 root root 138 Mar 30 03:59 runuser-l -rw-r--r-- 1 root root 2133 Mar 23 05:02 sshd -rw-r--r-- 1 root root 2257 Nov 20 02:11 su -rw-r--r-- 1 root root95 Mar 12 08:59 sudo -rw-r--r-- 1 root root 220 Apr 16 21:22 systemd-user -rw-r--r-- 1 root root 108 Oct 15 2014 xscreensaver I think I am using lightdm as display manager/login manager. (Any way to find out which is?) And in lightdm, lightdm-autologin and lightdm-greeter I see: # Load environment from /etc/environment and ~/.pam_environment auth required pam_env.so envfile=/etc/default/locale > If there is, check that pam_env.so is invoked. Apparently pam_env.so is alreadu being invoked. > If it is not, add it > by imitating another file that does it right (xdm for example) I really have no idea which file to add. > and file a > bug report. Where? -- Avinash Sonawane (RootKea) PICT, Pune http://www.rootkea.wordpress.com -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/caj9bsw9ftkdn5yzwtsrbctxgi3hfolwkujmplndwm7_irae...@mail.gmail.com
Re: sudo not respecting /etc/sudoers
Le quartidi 14 floréal, an CCXXIII, Jonathan Dowland a écrit : > This is inevitable with http_proxy, sadly, as there is no one place you can > put things that will guarantee that all processes with get them as environment > variables, and no guarantee that all processes will honour http_proxy anyway. This is true, but completely irrelevant in this case because the discussion is not about ALL processes, it is about this particular instance of the user's shell and apt-get. > There are drawbacks to doing it. With -E it's potentially passing > dangerous environment variables up to the super process. With whitelisting > the http_proxy you're exposing yourself to attacks where a malicious > person/process/whatever can point apt (or other things) at a malicious > http_proxy. Once again, this is true but irrelevant for this discussion. Sanitizing the environment against possible dangerous values is necessary when granting LIMITED privileges with sudo, i.e. allowing to run only some specific commands with elevated privileges. When granting UNLIMITED privileges, i.e. allowing to run any command with sudo, sanitizing the environment is just a matter of convenience. > Using 'sudo apt-get -o Acquire::http::Proxy=...' is so laborious that the > user is almost guaranteed to define a bash function or alias or something > else to save on typing. By which point they may as well have put it in the > apt configuration. And when the address of the proxy will change, they will have a hard figuring out what is wrong with apt-get. That is one of the drawback of your proposed solution. The major drawback, of course, is that you are suggesting a fix without having understood the problem first. This is a very bad habit. Regards, -- Nicolas George signature.asc Description: Digital signature
Re: /etc/environment not available for normal user while for root it is[was Re: sudo not respecting /etc/sudoers]
Le quartidi 14 floréal, an CCXXIII, Avinash Sonawane a écrit : > I am using Jessie with XFCE. Look in /etc/pam.d/ if there is a file related to xfce and its display manager. If there is, check that pam_env.so is invoked. If it is not, add it by imitating another file that does it right (xdm for example) and file a bug report. Regards, -- Nicolas George signature.asc Description: Digital signature
Re: sudo not respecting /etc/sudoers
Le quartidi 14 floréal, an CCXXIII, Jonathan Dowland a écrit : > There's nothing wrong with the file permissions. By default, root's > shell reads /etc/environment, but users do not. To be honest I'm not > sure why that is the case. I believe you are wrong. > You can configure your user(s) to source /etc/environment by adding '. > /etc/environment' to their ~/.bashrc files (assuming they still use bash). This is bugware. /etc/environment is read by PAM. If it is not, then the PAM configuration is faulty. As far as I can see, pam_env.so is invoked by each specific PAM configuration; IMHO, it should be in common-session. > To solve your specific apt-related problem, you can also add 'Defaults > env_file += /etc/environment' to sudoers and it will be sourced by sudo > when you use it to invoke another command. This is bugware. > (IMHO that's preferable to whitelisting the http_proxy env variable). It may be the case if sudo was used to grant LIMITED access to the user. When granting UNLIMITED access, whitelisting the environment variable is preferable. Regards, -- Nicolas George signature.asc Description: Digital signature
/etc/environment not available for normal user while for root it is[was Re: sudo not respecting /etc/sudoers]
I am using Jessie with XFCE. When I try to invoke any network using utility as normal user my /etc/environment is not getting used as if for normal user /etc/environment doesn't exist. While when I try to invoke the same utility as a root user the proxy set in /etc/environment just works as if /etc/environment exists for root user only. Here is my /etc/environment http://paste.debian.net/170960 `$ env` (as normal user) does not show any of the three proxy variables set in /etc/environment `# env` (as root user) displays all the three variables set in /etc/environment $ ls -la /etc/environment -rw-r--r-- 1 root root 117 May 2 17:41 /etc/environment Please help! -- Avinash Sonawane (RootKea) PICT, Pune http://rootkea.wordpress.com -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/caj9bsw947cq+xdmcgp36xanb9dr3a4m-toawuolpa7d71qg...@mail.gmail.com
Re: sudo not respecting /etc/sudoers
On Sun, May 03, 2015 at 05:09:20PM +0530, Avinash Sonawane wrote: > may be it's file permissions. For me > $ ls -la /etc/environment /etc/sudoers > -rw-r--r-- 1 root root 117 May 2 17:41 /etc/environment > -r--r- 1 root root 778 May 3 16:13 /etc/sudoers There's nothing wrong with the file permissions. By default, root's shell reads /etc/environment, but users do not. To be honest I'm not sure why that is the case. You can configure your user(s) to source /etc/environment by adding '. /etc/environment' to their ~/.bashrc files (assuming they still use bash). To solve your specific apt-related problem, you can also add 'Defaults env_file += /etc/environment' to sudoers and it will be sourced by sudo when you use it to invoke another command. (IMHO that's preferable to whitelisting the http_proxy env variable). However it wouldn't be in your user's environment and you might want it for wget, curl, etc. as a non-root user, too. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150503131131.gf29...@chew.redmars.org
Re: sudo not respecting /etc/sudoers
On Sun, May 03, 2015 at 11:59:29AM +0200, Nicolas George wrote: > On the other hand, that means that the HTTP proxy would be configured at two > different places. This is rarely a good idea, because one day the > configuration will change, and one of the places will be forgotten. This is inevitable with http_proxy, sadly, as there is no one place you can put things that will guarantee that all processes with get them as environment variables, and no guarantee that all processes will honour http_proxy anyway. The only alternative would be to set up and manage transparent proxying, with a whole load of other drawbacks. > Also: keeping the setting from the environment SHOULD WORK. If it does not, > there is a problem that needs fixing. Any other solution is not a fix, it is > a work-around. There are drawbacks to doing it. With -E it's potentially passing dangerous environment variables up to the super process. With whitelisting the http_proxy you're exposing yourself to attacks where a malicious person/process/whatever can point apt (or other things) at a malicious http_proxy. Note that the env whitelisting feature in sudo doesn't restrict what the value of the environment variables can be. Safer, if one is determined to solve this within sudo, would be to use env_file and define the http proxy in a file somewhere, such as /etc/environment. Using 'sudo apt-get -o Acquire::http::Proxy=...' is so laborious that the user is almost guaranteed to define a bash function or alias or something else to save on typing. By which point they may as well have put it in the apt configuration. > I do not know if the order if the directives in /etc/sudoers matters, as was > suggested earlier, but that would be the first thing to try. And of course, > use env to test, not apt. They don't, for aliases, but they do for user specifications. I believe the env_* options are considered aliases. See man sudoers for the fine details. -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/20150503125857.ge29...@chew.redmars.org
Re: sudo not respecting /etc/sudoers
On Sun, May 3, 2015 at 4:54 PM, Nicolas George wrote: > Le quartidi 14 floréal, an CCXXIII, Avinash Sonawane a écrit : >> No. Sorry for not being so clear. When I say `$ env` (i.e. as normal > > Do not worry, everyone forgets to check basic things from time to time. > >> user) it doesn't show http_proxy. As if /etc/environment is not >> available to normal user. I wonder why? (I checked file permissions >> they are 0644) >> >> When I say `# env` (i.e. as root user) I can see `http_proxy`, >> `https_proxy` and `ftp_proxy` as if /etc/environment is available to >> root only. > > So there you are: the problem is not with sudo, it is with the environment > of your normal user. > > Did you close your login session and start a fresh one since you changed > /etc/environment? I rebooted multiple times since then! may be it's file permissions. For me $ ls -la /etc/environment /etc/sudoers -rw-r--r-- 1 root root 117 May 2 17:41 /etc/environment -r--r- 1 root root 778 May 3 16:13 /etc/sudoers Any pointers? -- Avinash Sonawane (RootKea) PICT, Pune http://www.rootkea.wordpress.com -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/caj9bsw_fon+uxnqedlfp0rpfjc9kwv6ylok6myzfaquoo9q...@mail.gmail.com
Re: sudo not respecting /etc/sudoers
Le quartidi 14 floréal, an CCXXIII, Avinash Sonawane a écrit : > No. Sorry for not being so clear. When I say `$ env` (i.e. as normal Do not worry, everyone forgets to check basic things from time to time. > user) it doesn't show http_proxy. As if /etc/environment is not > available to normal user. I wonder why? (I checked file permissions > they are 0644) > > When I say `# env` (i.e. as root user) I can see `http_proxy`, > `https_proxy` and `ftp_proxy` as if /etc/environment is available to > root only. So there you are: the problem is not with sudo, it is with the environment of your normal user. Did you close your login session and start a fresh one since you changed /etc/environment? Regards, -- Nicolas George signature.asc Description: Digital signature
Re: sudo not respecting /etc/sudoers
Here is something. When I say `$ wget http://foobar` (normal user) then it says unable to resolve (proxy doesn't work) but when I say `# wget http://foobar` (root user) the resource gets downloaded (proxy works) So I think the real problem is /etc/environment is not getting used for normal user while root user seems to using it. Why? -- Avinash Sonawane (RootKea) PICT, Pune http://rootkea.wordpress.com -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CAJ9BSW_FYbCUN-9qoogDHH3D2_4fD77UArCBYzbTUens+Bta=g...@mail.gmail.com
Re: sudo not respecting /etc/sudoers
On Sun, May 3, 2015 at 4:27 PM, Nicolas George wrote: > Le quartidi 14 floréal, an CCXXIII, Avinash Sonawane a écrit : >> When I say `# env` I can see http_proxy=http://192.168.6.254:3128 but >> when I say `$ sudo env` there's no http_proxy variable printed. >> >> What's going on? > > I assume that you checked that "env" without "sudo" shows http_proxy? No. Sorry for not being so clear. When I say `$ env` (i.e. as normal user) it doesn't show http_proxy. As if /etc/environment is not available to normal user. I wonder why? (I checked file permissions they are 0644) When I say `# env` (i.e. as root user) I can see `http_proxy`, `https_proxy` and `ftp_proxy` as if /etc/environment is available to root only. Then when I say `$ sudo env` again I couldn't see any of the `http_proxy`, `https_proxy` or `ftp_proxy` > > If so, now, we know for sure that the problem is in sudo. The next test I > would suggest would be to have a single name in the "keep +=" directive: > > Defaults env_keep += http_proxy > > and see if it changes something. > > To Juha Heinanen: obviously your installation can access external HTTP sites > without a proxy. > > Regards, > > -- > Nicolas George -- Avinash Sonawane (RootKea) PICT, Pune http://www.rootkea.wordpress.com -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CAJ9BSW9_97nbzw8Wgej2t7N8m=ubsmr8tygo8ctvjfutait...@mail.gmail.com
Re: sudo not respecting /etc/sudoers
Avinash Sonawane writes: > > %sudo ALL=NOPASSWD: ALL > > What does this line do? NOPASSWD? it means that if someone is in sudo group, sudo command does not ask password. -- juha -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/21829.65438.760219.219...@tutpro.com
Re: sudo not respecting /etc/sudoers
On Sun, 3 May 2015 16:24:15 +0530 Avinash Sonawane wrote: > On Sun, May 3, 2015 at 3:58 PM, Juha Heinanen wrote: > > > %sudo ALL=NOPASSWD: ALL > > What does this line do? NOPASSWD? It lets you run commands as another user (normally root) without entering your password. Petter -- "I'm ionized" "Are you sure?" "I'm positive." pgpalFoSaAPmZ.pgp Description: OpenPGP digital signature
Re: sudo not respecting /etc/sudoers
Le quartidi 14 floréal, an CCXXIII, Avinash Sonawane a écrit : > When I say `# env` I can see http_proxy=http://192.168.6.254:3128 but > when I say `$ sudo env` there's no http_proxy variable printed. > > What's going on? I assume that you checked that "env" without "sudo" shows http_proxy? If so, now, we know for sure that the problem is in sudo. The next test I would suggest would be to have a single name in the "keep +=" directive: Defaults env_keep += http_proxy and see if it changes something. To Juha Heinanen: obviously your installation can access external HTTP sites without a proxy. Regards, -- Nicolas George signature.asc Description: Digital signature
Re: sudo not respecting /etc/sudoers
On Sun, May 3, 2015 at 3:58 PM, Juha Heinanen wrote: > %sudo ALL=NOPASSWD: ALL What does this line do? NOPASSWD? -- Avinash Sonawane (RootKea) PICT, Pune http://www.rootkea.wordpress.com -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CAJ9BSW8r6+R2qZ-9rrOjp61HNpmk=Rgz227ydbVfEQgkPv=x...@mail.gmail.com
Re: sudo not respecting /etc/sudoers
On Sun, May 3, 2015 at 4:09 PM, Nicolas George wrote: > Le quartidi 14 floréal, an CCXXIII, Avinash Sonawane a écrit : >> > 2) Move 'Defaults env_keep…' to line 12 in /etc/sudoers (i.e. *before* >> > "User privilege escalation section") >> Same error. Here's my updated /etc/sudoers http://paste.debian.net/170961/ > > The "env_keep" directive it still at the end. Maybe you pasted the wrong > file? Oops. Sorry! It's http://paste.debian.net/170991 > > Also: I believe you should test using env instead of apt-get: > > sudo env > > ... and see if http_proxy is still there. This would allow to distinguish > two possible problems: sudo not keeping the environment or apt-get not using > the environment. When I say `# env` I can see http_proxy=http://192.168.6.254:3128 but when I say `$ sudo env` there's no http_proxy variable printed. What's going on? -- Avinash Sonawane (RootKea) PICT, Pune http://www.rootkea.wordpress.com -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/caj9bsw9qg8ckfg3o-trwf52mbvp0up+ymh1tyfqdocdbxpo...@mail.gmail.com
Re: sudo not respecting /etc/sudoers
Le quartidi 14 floréal, an CCXXIII, Avinash Sonawane a écrit : > > 2) Move 'Defaults env_keep…' to line 12 in /etc/sudoers (i.e. *before* > > "User privilege escalation section") > Same error. Here's my updated /etc/sudoers http://paste.debian.net/170961/ The "env_keep" directive it still at the end. Maybe you pasted the wrong file? Also: I believe you should test using env instead of apt-get: sudo env ... and see if http_proxy is still there. This would allow to distinguish two possible problems: sudo not keeping the environment or apt-get not using the environment. Regards, -- Nicolas George signature.asc Description: Digital signature
Re: sudo not respecting /etc/sudoers
On Sun, May 3, 2015 at 2:50 PM, Reco wrote: > 2) Move 'Defaults env_keep…' to line 12 in /etc/sudoers (i.e. *before* > "User privilege escalation section") Same error. Here's my updated /etc/sudoers http://paste.debian.net/170961/ I think this might be relevant. I had previous configuration which has /etc/sudoers with env_keep at the very bottom. In newly installed system I installed `sudo`. Then I *copied* previous /etc/sudoers using `# cp ~/backup/sudoers /etc/sudoers` and then I added normal user to sudo group using `# adduser rootkea sudo` I thought I should have not copy pasted the sudoers and thought that was the cause of the problem so I purged sudo and then again installed it. And then added normal user to sudo and added env_keep to sudoers. But no luck. Still the same error. -- Avinash Sonawane (RootKea) PICT, Pune http://www.rootkea.wordpress.com -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/CAJ9BSW-NUThUjvYuPhXOG=ue2mpauuhqz16kobkctph5pg_...@mail.gmail.com
Re: sudo not respecting /etc/sudoers
In my jessie, 'sudo apt-get update' works fine without any special tricks: $ sudo apt-get update Get:1 http://ftp.fi.debian.org jessie InRelease [128 kB] ... My sudoers is below. I have changed only one line from the default. -- Juha # # This file MUST be edited with the 'visudo' command as root. # # Please consider adding local content in /etc/sudoers.d/ instead of # directly modifying this file. # # See the man page for details on how to write a sudoers file. # Defaultsenv_reset Defaultsmail_badpass Defaultssecure_path="/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/ sbin:/bin" # Host alias specification # User alias specification # Cmnd alias specification # User privilege specification rootALL=(ALL:ALL) ALL # Allow members of group sudo to execute any command #%sudo ALL=(ALL:ALL) ALL %sudo ALL=NOPASSWD: ALL # See sudoers(5) for more information on "#include" directives: #includedir /etc/sudoers.d -- To UNSUBSCRIBE, email to debian-user-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/21829.63583.856300.49...@tutpro.com
Re: sudo not respecting /etc/sudoers
Le quartidi 14 floréal, an CCXXIII, Jonathan Dowland a écrit : > The safest way would be a variation on 3), IMHO > > echo 'Acquire::http::Proxy "http://192.168.6.254:3128";;' | \ > sudo tee -a /etc/apt/apt.conf.d/90http-proxy > > This should make the setting persist and normal apt-get update/upgrade > should work afterwards. On the other hand, that means that the HTTP proxy would be configured at two different places. This is rarely a good idea, because one day the configuration will change, and one of the places will be forgotten. Also: keeping the setting from the environment SHOULD WORK. If it does not, there is a problem that needs fixing. Any other solution is not a fix, it is a work-around. I do not know if the order if the directives in /etc/sudoers matters, as was suggested earlier, but that would be the first thing to try. And of course, use env to test, not apt. Regards, -- Nicolas George signature.asc Description: Digital signature
