Re: Trying to solve file lock problem with /etc/sudoers

[Samuel Thibault]

Hello,

Peter Baumgarten, le Thu 13 Mar 2014 18:46:30 -0500, a écrit :
> I figured out why sudo was not building, unless I explicitly state a
> umask in my .profile that is NOT umask 000, which it seemed like it was.
> sudo will fail some permission checks. If put either umask 002 or 022
> in .profile sudo will build. So is there another bug with default file
> permissions then?

Having umask as 000 is very odd indeed.  How do you log into your system?

Samuel

Re: Trying to solve file lock problem with /etc/sudoers

[Peter Baumgarten]

I figured out why sudo was not building, unless I explicitly state a
umask in my .profile that is NOT umask 000, which it seemed like it was.
sudo will fail some permission checks. If put either umask 002 or 022
in .profile sudo will build. So is there another bug with default file
permissions then?


signature.asc
Description: This is a digitally signed message part

Re: Trying to solve file lock problem with /etc/sudoers

[Samuel Thibault]

Peter Baumgarten, le Fri 14 Mar 2014 22:33:42 -0500, a écrit :
> On Tue, 2014-03-11 at 10:15 +0100, Samuel Thibault wrote:
> > Another way is to just fix lockf in glibc (for now it is just returning
> > ENOSYS), it seems sudo simply locks the whole file, so it would be the
> > simple case to implement.
> 
> If I did want to fix lockf in glibc where would I find the lockf
> function to fix it and what should it look like or do when it is
> working?

I have already told you that:

“
The second part would be fixing lockf in glibc
in the simple case used by sudo, which is locking the whole file.
It should be a matter of calling some lseek() inside fcntl() in
glibc/sysdeps/mach/hurd/fcntl.c and check whether it happens to be 0,
instead of just returning errno=ENOTSUP in the SEEK_CUR case.
”

(the lockf function itself is in glibc/io/lockf.c)

Samuel

Re: Trying to solve file lock problem with /etc/sudoers

[Peter Baumgarten]

On Tue, 2014-03-11 at 10:15 +0100, Samuel Thibault wrote:
> Another way is to just fix lockf in glibc (for now it is just returning
> ENOSYS), it seems sudo simply locks the whole file, so it would be the
> simple case to implement.

If I did want to fix lockf in glibc where would I find the lockf
function to fix it and what should it look like or do when it is
working?



signature.asc
Description: This is a digitally signed message part

Re: Trying to solve file lock problem with /etc/sudoers

[Samuel Thibault]

Hello,

Peter Baumgarten, le Wed 12 Mar 2014 22:16:19 -0500, a écrit :
> I simply created a sudo directory and then ran apt-get --build source
> sudo as a normal user, and the part of the script where this is
> happening is debian/rules build inside of sudo-1.8.9p5 directory. The
> question I am asking is where should I go from here? I do not have much
> experience building debian packages from source.

I would rather use apt-get source, and then dpkg-buildpackage inside the
sudo-1.8.9p5 directory, but that's basically the same.

So if it's a test issue, you can probably at least override the failure
by setting

export DEB_BUILD_OPTIONS=nocheck

That being said, it would be better to just fix the failures.  Try to
run the test programs by hand, check their output, run in a debugger,
check where it starts going wrong, etc.

> I also noticed that the diff file for use-flock-on-hurd is for
> sudo-1.8.3p1 would the version mismatch cause problems at all?

That's not a problem: patches are applied with the -p1 option of the
patch command.

Samuel

Re: Trying to solve file lock problem with /etc/sudoers

[Peter Baumgarten]

On Tue, 2014-03-11 at 10:15 +0100, Samuel Thibault wrote:
> No, it's rather the locking function which spuriously fails. The
> debian/patches/use-flock-on-hurd.diff patch is supposed to make sudo use
> flock instead of lockf, but that doesn't seem to actually happen. Some
> autoconf patching is probably needed there to fix things.

I'm trying to fix the visudo problem and so I tried to build the deb
file from source, but it will not build on my qemu hurd instance. I can
not seem to understand the error messages that well, but I think that it
runs some test and on two of them sudo does not pass.  Specifically I
believe the tests are in
sudo-1.8.9p5/plugins/sudoers/regress/testsudoers/test2 and test3. 

I simply created a sudo directory and then ran apt-get --build source
sudo as a normal user, and the part of the script where this is
happening is debian/rules build inside of sudo-1.8.9p5 directory. The
question I am asking is where should I go from here? I do not have much
experience building debian packages from source.

I also noticed that the diff file for use-flock-on-hurd is for
sudo-1.8.3p1 would the version mismatch cause problems at all?


signature.asc
Description: This is a digitally signed message part

Re: Trying to solve file lock problem with /etc/sudoers

[Samuel Thibault]

Hello,

Peter Baumgarten, le Tue 11 Mar 2014 16:04:04 -0500, a écrit :
> I looked through the
> bugzilla list and did not know which bug I should tackle, but I was
> annoyed that I could not shutdown as a normal user because of the visudo
> problem, so I thought why not tackle that bug?

That's exactly the way I recommend: tackle a bug you actually care for
:)

Concerning that precise bug, I believe it should be quite easy:
debian/patches/use-flock-on-hurd.diff is really supposed to make
./configure switch to flock instead of the known-not-to-work lockf,
and that doesn't seem to be having effect: the buildd log shows that
./configure still believes lockf is available. You should check what
happens in the configure script, and fix the use-flock-on-hurd.diff
patch accordingly.  The second part would be fixing lockf in glibc
in the simple case used by sudo, which is locking the whole file.
It should be a matter of calling some lseek() inside fcntl() in
glibc/sysdeps/mach/hurd/fcntl.c and check whether it happens to be 0,
instead of just returning errno=ENOTSUP in the SEEK_CUR case.

Samuel

Re: Trying to solve file lock problem with /etc/sudoers

[Peter Baumgarten]

On Tue, 2014-03-11 at 10:29 +0100, Thomas Schwinge wrote:
> You don't happen to be a student willing to do this as a Google Summer of
> Code project?  :-)

Yes I am a student hoping to get involved with hurd development through
Google Summer of Code. I saw on the application that I should have
submitted a patch to squash at least one bug. I looked through the
bugzilla list and did not know which bug I should tackle, but I was
annoyed that I could not shutdown as a normal user because of the visudo
problem, so I thought why not tackle that bug? On IRC my nick is petroz



signature.asc
Description: This is a digitally signed message part

Re: Trying to solve file lock problem with /etc/sudoers

[Thomas Schwinge]

Hi!

On Tue, 11 Mar 2014 02:44:36 -0500, Peter Baumgarten 
 wrote:
> I'm trying to be a hurd developer by jumping straight in and trying to
> tackle a bug.

So, welcome to the team!  :-)

> This may not be a hurd bug, but I only see it with the
> hurd version of sudo. I am trying to figure out why I get this message
> "visudo: /etc/sudoers busy, try again later" when I run visudo as root.

It's always a good idea to first look which issues already are known.
, *Working
on a Checkout of the Git Repository*, *Getting the Sources*:

$ git clone git://git.savannah.gnu.org/hurd/web.git
$ cd web/
$ git grep -C3 sudoers
open_issues/visudo.mdwn-is included in the section entitled [[GNU Free 
Documentation
open_issues/visudo.mdwn-License|/fdl]]."]]"""]]
open_issues/visudo.mdwn-
open_issues/visudo.mdwn:[[!meta title="visudo: /etc/sudoers is busy, try 
again later"]]
open_issues/visudo.mdwn-
open_issues/visudo.mdwn-[[!tag open_issue_hurd]]
open_issues/visudo.mdwn-
open_issues/visudo.mdwn-visudo does not work:
open_issues/visudo.mdwn-
open_issues/visudo.mdwn:/etc/sudoers is busy, try again later
open_issues/visudo.mdwn-
open_issues/visudo.mdwn-Apparently there is some locking that sudo does 
which does not
open_issues/visudo.mdwn-work. Uninvestigated for now.
open_issues/visudo.mdwn-
open_issues/visudo.mdwn:One can just edit the /etc/sudoers file and take 
care of correctness by hand.

(Alternatively, use the seach box on the upper right of
.)

So, the issue already is known,
.  ... but that
page doesn't tell what's going on.

> I suspect something has a file lock on /etc/sudoers. I would normally
> use lsof to see what processes have a lock on a file, but apparently
> lsof is not available for hurd. When I say not available I mean not
> installed by default on the debian hurd qemu image and not available in
> the debian hurd repos. Does anyone know what tools are available to me
> to see what has a lock on file or what processes are using a file on?

$ git grep lsof
hurd/debugging.mdwn: but something that would be reusable in 
lsof
hurd/debugging.mdwn:  because you used lsof right ?
hurd/debugging.mdwn: ah, well, ok, but if we put it in the 
signal thread, then lsof
hurd/translator/term.mdwn: (see why we need a global lsof :p)
open_issues/lsof.mdwn:We don't have a `lsof` tool.  Perhaps we could cook 
something with having a
open_issues/lsof.mdwn: basically, lsof
open_issues/lsof.mdwn: lsof and pmap and two tools we really 
lack on the hurd

Indeed we don't have lsof.  If hitting such a (presumed) bug on a
Linux-based system, I probably first would use strace to figure out what
exactly visudo is doing.  Another web pages search, for strace, leads to
, so
rpctrace is the tool to use on a Hurd system, in parallel with looking
into visudo's source code.  (As rpctrace will show RPCs, you'd have to
trace back which (glibc) library function calls these are being done for.
For some more context, see
 and, for example, the
text I recently wrote on

for how this works on a Hurd system.)

And yes, there indeed are issues with file (record) locking on Hurd, in
particular the lockf interface:

$ git grep lockf\\\>
community/gsoc/project_ideas/file_locking.mdwn:them. The biggest missing 
feature is record locking, i.e. the lockf variant,
open_issues/file_locking.mdwn: (which is independant from lockf 
from the locking point of view,

So, if you can confirm that visudo is using lockf (or something else that
is not yet supported), you can already note that on the
open_issues/visudo page (either web interface, or send a patch;
), and then
it seems you'd have to work on completing the file locking interfaces.


You don't happen to be a student willing to do this as a Google Summer of
Code project?  :-)


Grüße,
 Thomas


pgp72MemygxhS.pgp
Description: PGP signature

Re: Trying to solve file lock problem with /etc/sudoers

[Richard Braun]

On Tue, Mar 11, 2014 at 02:44:36AM -0500, Peter Baumgarten wrote:
> I'm trying to be a hurd developer by jumping straight in and trying to
> tackle a bug. This may not be a hurd bug, but I only see it with the
> hurd version of sudo. I am trying to figure out why I get this message
> "visudo: /etc/sudoers busy, try again later" when I run visudo as root.
> I suspect something has a file lock on /etc/sudoers. I would normally
> use lsof to see what processes have a lock on a file, but apparently
> lsof is not available for hurd. When I say not available I mean not
> installed by default on the debian hurd qemu image and not available in
> the debian hurd repos. Does anyone know what tools are available to me
> to see what has a lock on file or what processes are using a file on?

To everyone who's trying to be a free software contributor, this is the
right (or at least recommended) approach.

The Hurd is a distributed system, and it's not straightforward to come
up with tools like lsof. The closest one is probably portinfo, but it
won't give you as much information. The issue is known, although I'm
not familiar with the details. You need to understand the general
architecture of the Hurd, and then dig in libdiskfs/libfshelp and the
ext2fs translator, I suppose. It is definitely a Hurd bug, which may
require development (i.e. it may be a feature missing, not a mere bug).

Unless I'm mistaken, the issue is described on the wiki [1].

-- 
Richard Braun

[1] http://darnassus.sceen.net/~hurd-web/open_issues/file_locking/

Re: Trying to solve file lock problem with /etc/sudoers

[Samuel Thibault]

I forgot to answer the other question: no, there is no support for lsof
on the Hurd yet.

Samuel

Re: Trying to solve file lock problem with /etc/sudoers

[Samuel Thibault]

Hello,

Peter Baumgarten, le Tue 11 Mar 2014 02:44:36 -0500, a écrit :
> I'm trying to be a hurd developer by jumping straight in and trying to
> tackle a bug.

Good!

> This may not be a hurd bug, but I only see it with the
> hurd version of sudo.

It is a hurd bug.

> I am trying to figure out why I get this message
> "visudo: /etc/sudoers busy, try again later" when I run visudo as root.
> I suspect something has a file lock on /etc/sudoers.

No, it's rather the locking function which spuriously fails. The
debian/patches/use-flock-on-hurd.diff patch is supposed to make sudo use
flock instead of lockf, but that doesn't seem to actually happen. Some
autoconf patching is probably needed there to fix things.

Another way is to just fix lockf in glibc (for now it is just returning
ENOSYS), it seems sudo simply locks the whole file, so it would be the
simple case to implement.

Samuel